[TEST] Switch to persistent settings in java tests#78562
[TEST] Switch to persistent settings in java tests#78562grcevski merged 15 commits intoelastic:masterfrom
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) |
rjernst
left a comment
There was a problem hiding this comment.
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.
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.
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.
| try { | ||
| client().admin().cluster() | ||
| .prepareUpdateSettings() | ||
| .setTransientSettings(Settings.builder().put(key1, value1).build()) |
There was a problem hiding this comment.
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.
We should keep this test but handle the deprecation warning.
| .put("cluster.acc.test.pw", "asdf") | ||
| .put("cluster.acc.test.user", "asdf")).get(); | ||
|
|
||
| iae = expectThrows(IllegalArgumentException.class, () -> |
There was a problem hiding this comment.
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. |
rjernst
left a comment
There was a problem hiding this comment.
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.
Why the method name change? This is still calling randomSettings internally right?
There was a problem hiding this comment.
Yeah good point, it was doing double random before :). I'll change it back.
| -------------------------------------------------- | ||
| include-tagged::{doc-tests-file}[{api}-request-cluster-settings] | ||
| -------------------------------------------------- | ||
| <1> Sets the transient settings to be applied |
There was a problem hiding this comment.
Shouldn't the docs stay for transient settings until we actually remove the feature?
There was a problem hiding this comment.
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