-
Notifications
You must be signed in to change notification settings - Fork 25.1k
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
[TEST] Switch to persistent settings in java tests #78562
[TEST] Switch to persistent settings in java tests #78562
Conversation
We are deprecating transient settings, therefore this PR changes uses of transient cluster settings to persistent cluster settings.
Pinging @elastic/es-core-infra (Team:Core/Infra) |
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 looks good in general for tests that were unnecessarily using transient settings, but for tests of the settings infrastructure itself I think we need to keep the tests, in some form.
|
||
public class ClusterClientIT extends ESRestHighLevelClientTestCase { | ||
|
||
public void testClusterPutSettings() throws IOException { | ||
final String transientSettingKey = RecoverySettings.INDICES_RECOVERY_MAX_BYTES_PER_SEC_SETTING.getKey(); |
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 keep some direct test(s) for transient settings, we’ll just need to handle the deprecation warning. They can go in dedicated test methods though, so they are easily removed in the future.
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 decided to leave few of these inside the existing methods since they test combinations of persistent and transient settings used together. All of those that were pure transient settings usage are parameterized to try both transient and persistent.
@@ -51,11 +50,11 @@ public void testClusterNonExistingSettingsUpdate() { | |||
try { | |||
client().admin().cluster() | |||
.prepareUpdateSettings() | |||
.setTransientSettings(Settings.builder().put(key1, value1).build()) |
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 test case where we may want to keep some dedicated tested for transient settings.
@@ -82,10 +81,6 @@ public void testUpgradePersistentSettingsOnUpdate() { | |||
runUpgradeSettingsOnUpdateTest((settings, builder) -> builder.setPersistentSettings(settings), Metadata::persistentSettings); | |||
} | |||
|
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 keep this test but handle the deprecation warning.
assertEquals("missing required setting [cluster.acc.test.user] for setting [cluster.acc.test.pw]", iae.getMessage()); | ||
client().admin().cluster().prepareUpdateSettings().setPersistentSettings(Settings.builder() | ||
.put("cluster.acc.test.pw", "asdf") | ||
.put("cluster.acc.test.user", "asdf")).get(); | ||
|
||
iae = expectThrows(IllegalArgumentException.class, () -> |
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 test we should keep but separate.
Sounds good! I'll bring back the transient settings in those places and rework it a bit so we can handle the warning. |
Revert back tests that test specifically for the transient settings functionality.
I brought back those tests and extracted where I could to use both transient and persistent settings. |
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. A couple last minor questions
} else { | ||
return Metadata.builder(metadata).transientSettings(randomSettings(metadata.transientSettings())).build(); | ||
} | ||
private Metadata metadataSettings(Metadata metadata) { |
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.
Why the method name change? This is still calling randomSettings internally right?
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 good point, it was doing double random before :). I'll change it back.
@@ -26,8 +26,7 @@ At least one setting to be updated must be provided: | |||
-------------------------------------------------- | |||
include-tagged::{doc-tests-file}[{api}-request-cluster-settings] | |||
-------------------------------------------------- | |||
<1> Sets the transient settings to be applied |
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.
Shouldn't the docs stay for transient settings until we actually remove the feature?
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.
Thanks, yeah I wasn't sure what should we do here. I thought if we are deprecating them we shouldn't be advertising them as an available option anymore, but I'll bring it back and perhaps I'll label the usage as deprecated where needed.
Migrate to persistent cluster settings in Java tests We are deprecating transient settings, therefore this PR changes uses of transient cluster settings to persistent cluster settings.
💚 Backport successful
|
We are deprecating transient cluster settings in 7.16.0, so this PR
changes various uses of transient settings in Java tests to use
persistent cluster settings instead.
Relates to #49540