Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exposing the ability to log deprecated settings at non-critical level #79107

Conversation

masseyke
Copy link
Member

@masseyke masseyke commented Oct 13, 2021

A recent change for the deprecation logs provided the capability to emit deprecation's at critical vs. warning levels, #77482.
However deprecated settings always log at critical level without the ability to express that the setting deprecation is only a
warning.

This commit exposes the ability to set the deprecation level when deprecating a setting.
Relates #78781

@masseyke masseyke added the :Core/Infra/Logging Log management and logging utilities label Oct 13, 2021
@elasticmachine elasticmachine added the Team:Core/Infra Meta label for core/infra team label Oct 13, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (Team:Core/Infra)

@masseyke
Copy link
Member Author

@elasticmachine update branch

Copy link
Member

@rjernst rjernst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good in general, I just have a few comments about not adding more variants of methods in HeaderWarning and ESTestCase.

addWarning(THREAD_CONTEXT, DeprecationLogger.CRITICAL, message, params);
}

public static void addWarning(Level level, String message, Object... params) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than adding another public method, can you please update the existing uses? It looks like there are ~12 calls to the existing method, and most are in tests, it should be easy to update with eg IntelliJ refactoring tools to add a parameter.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I went back and forth on this. I actually did this and backed it out in an attempt to make this PR smaller. I'll consolidate it into one method.

@@ -193,10 +196,14 @@ private static boolean assertWarningValue(final String s, final String warningVa
* @return a warning value formatted according to RFC 7234
*/
public static String formatWarning(final String s) {
return formatWarning(DeprecationLogger.CRITICAL, s);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another method seems unnecessary, the only non-test use is in this class, let's just update the few tests using this to pass the level?

@@ -99,10 +99,15 @@
Final,

/**
* mark this setting as deprecated
* mark this setting as deprecated (critical level)
*/
Deprecated,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice, as a followup (since it will touch so many files), to rename this.

}

private boolean isDeprecatedWarningOnly() {
return properties.contains(Property.DeprecatedWarning) && properties.contains(Property.Deprecated) == false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should assert somewhere that both properties do not exist, they should be mutually exclusive. Then this method isn't needed, just check for contains the warning version?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added this to the Setting constructor, and updated this method..

Arrays.stream(warnings))
.toArray(String[]::new));
}

protected final void assertWarnings(String... expectedWarnings) {
assertWarnings(true, expectedWarnings);
}

protected final void assertWarnings(boolean stripXContentPosition, String... expectedWarnings) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are 4 uses of this method. Let's update those to call the updated signature rather than adding yet another variant.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@@ -458,11 +460,35 @@ protected final void assertSettingDeprecationsAndWarnings(final String[] setting
.toArray(String[]::new));
}

protected final void assertSettingDeprecationsAndWarningsIncludingLevel(final Setting<?>[] settings, final String... warnings) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are only 2 uses of the method above which takes string setting names. Let's collapse all 3 of these methods into one, this is unwieldy having 3 methods of the same name, with no clear distinction of when to call each.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is another one I'd gone back and forth on. I've merged them all into one method now.

@masseyke
Copy link
Member Author

@elasticmachine update branch

@elasticmachine
Copy link
Collaborator

merge conflict between base and head

@masseyke masseyke requested a review from rjernst October 15, 2021 17:05
Copy link
Member

@rjernst rjernst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, but one last question

*
* @param settings the settings that are expected to be deprecated
* @param settings the settings that are expected to be deprecated
* @param shouldAssertExpectedLogLevel
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

docs?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed this param (since it's no longer optional).

}

protected final void assertSettingDeprecationsAndWarnings(final String[] settings, final String... warnings) {
protected final void assertSettingDeprecationsAndWarnings(final Setting<?>[] settings, boolean shouldAssertExpectedLogLevel,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I missed this before, I thought it was just settings and warnings, why wouldn't we always assert the expected log level?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah no real harm in checking it for everything, and it might be useful in the future. I've added that.

@masseyke masseyke requested a review from rjernst October 18, 2021 23:13
Copy link
Member

@rjernst rjernst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@masseyke masseyke merged commit 88250c2 into elastic:master Oct 19, 2021
weizijun added a commit to weizijun/elasticsearch that referenced this pull request Oct 19, 2021
* upstream/master:
  Validate tsdb's routing_path (elastic#79384)
  Adjust the BWC version for the return200ForClusterHealthTimeout field (elastic#79436)
  API for adding and removing indices from a data stream (elastic#79279)
  Exposing the ability to log deprecated settings at non-critical level (elastic#79107)
  Convert operator privilege license object to LicensedFeature (elastic#79407)
  Mute SnapshotBasedIndexRecoveryIT testSeqNoBasedRecoveryIsUsedAfterPrimaryFailOver (elastic#79456)
  Create cache files with CREATE_NEW & SPARSE options (elastic#79371)
  Revert "[ML] Use a new annotations index for future annotations (elastic#79151)"
  [ML] Use a new annotations index for future annotations (elastic#79151)
  [ML] Removing legacy code from ML/transform auditor (elastic#79434)
  Fix rate agg with custom `_doc_count` (elastic#79346)
  Optimize SLM Policy Queries (elastic#79341)
  Fix execution of exists query within nested queries on field with doc_values disabled (elastic#78841)
  Stricter UpdateSettingsRequest parsing on the REST layer (elastic#79227)
  Do not release snapshot file download permit during recovery retries (elastic#79409)
  Preserve request headers in a mixed version cluster (elastic#79412)
  Adjust versions after elastic#79044 backport to 7.x (elastic#79424)
  Mute BulkByScrollUsesAllScrollDocumentsAfterConflictsIntegTests (elastic#79429)
  Fail on SSPL licensed x-pack sources (elastic#79348)

# Conflicts:
#	server/src/test/java/org/elasticsearch/index/TimeSeriesModeTests.java
@masseyke masseyke mentioned this pull request Oct 19, 2021
masseyke added a commit that referenced this pull request Oct 19, 2021
As #79107 of the ESTestCase assertWarnings methods now check that the log level is of the expected type. This commit
puts in the correct expected log level.
Relates #79107 #78921
masseyke added a commit to masseyke/elasticsearch that referenced this pull request Oct 19, 2021
…elastic#79107)

A recent change for the deprecation logs provided the capability to emit deprecation's at critical vs. warning levels, elastic#77482.
However deprecated settings always log at critical level without the ability to express that the setting deprecation is only a
warning.

This commit exposes the ability to set the deprecation level when deprecating a setting.
Closes elastic#78781
masseyke added a commit that referenced this pull request Oct 19, 2021
…79107) (#79492)

A recent change for the deprecation logs provided the capability to emit deprecation's at critical vs. warning levels, #77482.
However deprecated settings always log at critical level without the ability to express that the setting deprecation is only a
warning.

This commit exposes the ability to set the deprecation level when deprecating a setting.
Relates #78781
jakelandis added a commit that referenced this pull request Oct 27, 2021
… in 8.0 (#79665)

This commit lowers the severity for all settings from critical to warning
for all settings that are still present in 8.0.0.

releated #79107
@masseyke masseyke deleted the feature/deprecated-settings-at-warning-level-master branch November 2, 2021 17:48
masseyke added a commit that referenced this pull request Nov 8, 2021
This commit changes the deprecation logger so that all messages (critical or warning) are written
out with "299" as the level at the beginning of the header in order to be compliant with
https://www.rfc-editor.org/rfc/rfc7234.html#section-5.5.7. In #79107 we mistakenly began logging
warning-level messages with the 300 code, which is not valid in the RFC.
masseyke added a commit to masseyke/elasticsearch that referenced this pull request Nov 8, 2021
…#80304)

This commit changes the deprecation logger so that all messages (critical or warning) are written
out with "299" as the level at the beginning of the header in order to be compliant with
https://www.rfc-editor.org/rfc/rfc7234.html#section-5.5.7. In elastic#79107 we mistakenly began logging
warning-level messages with the 300 code, which is not valid in the RFC.
masseyke added a commit to masseyke/elasticsearch that referenced this pull request Nov 8, 2021
…#80304)

This commit changes the deprecation logger so that all messages (critical or warning) are written
out with "299" as the level at the beginning of the header in order to be compliant with
https://www.rfc-editor.org/rfc/rfc7234.html#section-5.5.7. In elastic#79107 we mistakenly began logging
warning-level messages with the 300 code, which is not valid in the RFC.
elasticsearchmachine pushed a commit that referenced this pull request Nov 8, 2021
…#80501)

This commit changes the deprecation logger so that all messages (critical or warning) are written
out with "299" as the level at the beginning of the header in order to be compliant with
https://www.rfc-editor.org/rfc/rfc7234.html#section-5.5.7. In #79107 we mistakenly began logging
warning-level messages with the 300 code, which is not valid in the RFC.
masseyke added a commit that referenced this pull request Nov 8, 2021
…#80503)

* Changing HeaderWarning to always use 299 as the warning code (#80304)

This commit changes the deprecation logger so that all messages (critical or warning) are written
out with "299" as the level at the beginning of the header in order to be compliant with
https://www.rfc-editor.org/rfc/rfc7234.html#section-5.5.7. In #79107 we mistakenly began logging
warning-level messages with the 300 code, which is not valid in the RFC.

* fixing compilation errors from merge
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Core/Infra/Logging Log management and logging utilities >deprecation Team:Core/Infra Meta label for core/infra team v7.16.0 v8.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants