-
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
Clean Up Snapshot Create Rest API #31779
Conversation
Pinging @elastic/es-core-infra |
@javanna I believe I have addressed all the issues from the previous review. |
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
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 @jdconrad - well done. I left few comments - there are really cosmetic ones
@@ -38,6 +40,14 @@ | |||
*/ | |||
public class CreateSnapshotResponse extends ActionResponse implements ToXContentObject { | |||
|
|||
private static final ObjectParser<CreateSnapshotResponse, Void> CREATE_SNAPSHOT_RESPONSE_PARSER = |
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'd prefer a short name - just PARSER
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.
@@ -2069,6 +2069,8 @@ public void testCreateSnapshot() throws IOException { | |||
expectedParams.put("wait_for_completion", waitForCompletion.toString()); |
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 can't comment line 2065 here (it's 4 lines above)
Boolean waitForCompletion = randomBoolean();
- no any reason for autoboxing
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 use the toString method from it for convenience.
|
||
static { | ||
CREATE_SNAPSHOT_RESPONSE_PARSER.declareObject(CreateSnapshotResponse::setSnapshotInfoFromBuilder, | ||
SnapshotInfo.SNAPSHOT_INFO_PARSER, new ParseField("snapshot")); |
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 think it would be better to simplify SNAPSHOT_INFO_PARSER
to just PARSER
as we use class reference
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 going to leave this one for now because there are two parsers in SnapshotInfo.
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 question, thanks @jdconrad !
@@ -54,6 +55,7 @@ public RestChannelConsumer prepareRequest(final RestRequest request, final NodeC | |||
request.applyContentParser(p -> createSnapshotRequest.source(p.mapOrdered())); | |||
createSnapshotRequest.masterNodeTimeout(request.paramAsTime("master_timeout", createSnapshotRequest.masterNodeTimeout())); | |||
createSnapshotRequest.waitForCompletion(request.paramAsBoolean("wait_for_completion", false)); | |||
createSnapshotRequest.indicesOptions(IndicesOptions.fromRequest(request, createSnapshotRequest.indicesOptions())); |
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 missing why we need to add support for these params as request parameters. Aren't they part of the request body for this API? Are they still supported in the body, meaning do we parse them back when reading the request body?
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.
indicesOptions
is never a part of request body (e.g. RequestConverters#deleteIndex) - the biggest question is here - shall we drop in from request itself (i have some doubt on that) and do follow rest api spec - or we have to maintain it properly and add to rest api spec to reflect it ?
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.
@vladimirdolzhenko you are referring to delete index, but create snapshot is a different API . See its docs: https://www.elastic.co/guide/en/elasticsearch/reference/6.3/modules-snapshots.html#_snapshot . It seems like ignore_unavailable (which is one of the indices options), as well as index, are specified in the request body. That's why I am asking on what we intend to do here.
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 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.
@javanna @vladimirdolzhenko I like the consistency and methods available for switching to indices options the way delete index is doing it; however at the same time, it's probably not worth deprecating the current way right now. My instinct is to revert this to how it was for now, and we can decide if we want to switch them to parameters at a later time. Would that work for you guys?
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 that's a good idea. let's discuss API changes separately.
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.
@javanna Will do. Thanks for the review here!
@vladimirdolzhenko No need to apologize! What you showed me makes a lot of sense for a future improvement.
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.
Reverted.
@javanna I reverted the API changes, and I think this is good to go now. Would you please take a look when you get a chance? Thanks in advance! |
@elasticmachine Test this please. |
1 similar comment
@elasticmachine Test this 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.
I left one small comment LGTM otherwise
@@ -433,8 +433,6 @@ public XContentBuilder toXContent(XContentBuilder builder, Params params) throws | |||
if (indicesOptions != null) { | |||
indicesOptions.toXContent(builder, params); | |||
} | |||
builder.field("wait_for_completion", waitForCompletion); | |||
builder.field("master_node_timeout", masterNodeTimeout.toString()); |
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.
good catch , these should not be printed out, nor parsed back, they are query_string parameters.
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.
Credit to @vladimirdolzhenko for pointing this out.
builder.field("allow_no_indices", allowNoIndices()); | ||
builder.field("forbid_aliases_to_multiple_indices", allowAliasesToMultipleIndices() == false); | ||
builder.field("forbid_closed_indices", forbidClosedIndices()); | ||
builder.field("ignore_aliases", ignoreAliases()); |
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 one ends up sending parameters that are getting ignored, see IndicesOptions.fromMap
. we should remove the last three parameters. This should be cleaned up, the problem is that some indices options are settable at REST, while some other are internal properties that define each API (the default argument in fromMap
) which cannot be changed, so they should never be printed out nor parsed back.
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.
Removed. Makes sense that we only print out what can be input.
@javanna Thanks for the review here! Will commit once the CI passes. |
Make SnapshotInfo and CreateSnapshotResponse parsers lenient for backwards compatibility. Remove extraneous fields from CreateSnapshotRequest toXContent.
* es/6.x: Use correct formatting for links (#29460) Revert "Adds a new auto-interval date histogram (#28993)" Revert "fix typo" fix typo Adds a new auto-interval date histogram (#28993) [Rollup] Replace RollupIT with a ESRestTestCase version (#31977) [Rollup] Fix duplicate field names in test (#32075) [Tests] Fix failure due to changes exception message (#32036) [Test] Mute MlJobIT#testDeleteJobAfterMissingAliases Replace Ingest ScriptContext with Custom Interface (#32003) (#32060) Cleanup Duplication in `PainlessScriptEngine` (#31991) (#32061) HLRC: Add xpack usage api (#31975) Clean Up Snapshot Create Rest API (#31779)
Fixes some issues brought up after this PR (#31215) was already merged. Also fixes issues related to indices options where they should be parameters rather than part of the request body.