-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Exposing the ability to log deprecated settings at non-critical level #79107
Conversation
Pinging @elastic/es-core-infra (Team:Core/Infra) |
@elasticmachine update branch |
There was a problem hiding this 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) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
… github.com:masseyke/elasticsearch into feature/deprecated-settings-at-warning-level-master
@elasticmachine update branch |
merge conflict between base and head |
There was a problem hiding this 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
docs?
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
* 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
…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
…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
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.
…#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.
…#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.
…#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.
…#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
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