-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Add Cluster Put Settings API to the high level REST client #28633
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
Conversation
|
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
1 similar comment
|
Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually? |
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.
hey @javanna I need some help with the naming?
In the rest-api-specs the api is cluster.put_settings, in the transport client and in the issue it is updateSettings. Should I rename to putSettings or leave it as updateSettings?
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.
let's follow the SPEC and make it putSettings please ;)
javanna
left a comment
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.
left some comments, looks good though, thanks @olcbean !
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.
s/Indices API/Cluster API
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.
let's follow the SPEC and make it putSettings please ;)
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.
s/transiet/transient
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.
s/transiet/transient
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 these two changes? I meant to to randomly choose one of the two branches, but then still set the param only randomly.
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.
if (randomBoolean()) is already wrapped in the setRandom*. If we keep it here, then waitForRandomShards is set to a random value only 25% of the time.
I assumed that it was an oversight...
private static void setRandomWaitForActiveShards(Consumer<ActiveShardCount> setter, Map<String, String> expectedParams) {
if (randomBoolean()) {
String waitForActiveShardsString;
int waitForActiveShards = randomIntBetween(-1, 5);
if (waitForActiveShards == -1) {
waitForActiveShardsString = "all";
} else {
waitForActiveShardsString = String.valueOf(waitForActiveShards);
}
setter.accept(ActiveShardCount.parseString(waitForActiveShardsString));
expectedParams.put("wait_for_active_shards", waitForActiveShardsString);
}
}
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.
oh right :) thanks
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.
shall we move RestClusterUpdateSettingsAction to use RestToXContentListener?
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.
rename the file to put_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.
s/clustre/cluster
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.
the docs don't quite build, could you fix that up?
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.
you mean as a map?
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.
cluster api -> Cluster API
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.
Fix Clustre
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.
resetRequest
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'm wondering if splitting this into 2 parts, one for the transient settings and one for the persistent ones would be more readable?
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.
Missing latch.await()
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.
Fxi Settigs ;)
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.
"to be updated"?
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.
Could it be more descriptive?
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 would like to shorten these ones by removing the leading Indicates. However it is used with Indicates in the indices section.
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.
ops :)
javanna
left a comment
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 @olcbean I left some more comments.
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.
nit: we could make these constants of type ParseField and then below in toXContent call field.getPreferredName()
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 for these changes
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.
can you remove the generic type? <> should be enough
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.
inserting random fields is not a good idea for requests. we should parse them strictly. In fact if this test succeeds it means that we have a bug :) we should rather test that we are strict when parsing requests.
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 a test to make sure that inserting random fields fails here. Or is it too much?
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.
given that in most cases we have two different test methods for this (with and without random fields), maybe we should not add this new method and rather do it like we did up until now? That said, I think I was not very diligent on this :)
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.
trying to figure out what happens when random fields are inserted among settings. I would expect the test to fail somehow, or maybe the arbitrary fields get parsed as setting and that is why you don't compare the two maps directly?
I wonder if randomizing at this level should be disabled, as its goal would be to verify that we are forward compatible when parsing, meaning that we will ignore a field/object if we don't know about it, as it could be a field added in a more recent 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.
The Settings will be simply parsed ( no strict validation ) and during execution will be compared tp the supported settings. I will disable the randomization for the settings, then the check is only for the 'top-level' fields.
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.
ignoreUnknownFields should be set to false here, as it is a request
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 am sorry, can you change the title to Cluster Update Settings API, like we have in the es docs? Confusing, I know :)
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.
would you mind wrapping these lines so they look better in the rendered docs?
754e38a to
dda7951
Compare
javanna
left a comment
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 left a few nits, this is ready though.
| .put(persistentSettingKey, persistentSettingValue) | ||
| .build(); // <2> | ||
| // end::put-settings-create-settings | ||
| // @formatter:on |
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.
these are eclipse specific tags right? I don't think we'd want them in our code.
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.
According to the docs IntelliJ also supports them.
By default these tags are ignored ( at least for eclipse formatters ). I added them to make clear that these sections intentionally are not following the ES formatting rules.
Should I remove them?
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.
yes please I haven't seen them used before in our codebase. At some point we will automate formatting and these classes will have to somehow be ignored I think.
| p -> p.startsWith("transient") || p.startsWith("persistent"), random()); | ||
| IllegalArgumentException e = expectThrows(IllegalArgumentException.class, | ||
| () -> ClusterUpdateSettingsRequest.fromXContent(createParser(xContentType.xContent(), mutated))); | ||
| assertTrue(e.getMessage().matches("\\[cluster_update_settings_request\\] unknown field \\[\\w*\\], parser not found")); |
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.
maybe instead of randomizing, you could just have added a specific test method with a non randomized json that contains un unsupported field, to verify that an error is thrown. Just to simplify things a bit.
| import static java.util.Collections.emptyMap; | ||
| import static java.util.Collections.singletonList; | ||
| import static org.elasticsearch.common.util.CollectionUtils.arrayAsArrayList; | ||
| import static org.elasticsearch.test.XContentTestUtils.insertRandomFields; |
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.
leftover?
| [[java-rest-high-cluster-put-settings]] | ||
| === Cluster Update Settings API | ||
|
|
||
| The Cluster Put Settings API allows to update cluster wide 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.
s/Put/Update ?
|
jenkins please test this |
correct docs remove tags disabling auto formatting
ef66147 to
131a05f
Compare
|
retest this please |
|
thanks again @olcbean ! |
Add Cluster Put Settings API to the high level REST client
( equivalent to Cluster Update Setting in transport client )
Relates to #27205