-
Notifications
You must be signed in to change notification settings - Fork 25.2k
HLRC: Add remove index lifecycle policy #34204
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
Pinging @elastic/es-core-infra |
} | ||
|
||
@Override | ||
public RemoveIndexLifecyclePolicyRequest indices(String... indices) { |
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 a question, not a change request: What is our philosophy regarding having setters vs. immutable request objects going forward for the HLRC? I've been under the impression we preferred immutable objects, but it doesn't seem to be consistent.
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.
@gwbrown Good question that I would like to know the answer to myself :). I was mostly going off what I saw within the set index lifecycle policy classes since that's the analog to this 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 think the most important thing is for the API to be built in a way where you cannot create invalid requests. It would be good if any mandatory fields in the request were passed into the constructor and don't have setters. The reason this was done for the server side was because the request extends IndicesRequest.Replaceable
but I think in order to achieve the client separation we want we actually can't extend that 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.
yea Im all for not exetnding that class. And Im also all for putting things that are primitive and easily validatable into the constructors. Optionals, i think im ok with setters but i think this also deserves a wider audience to discuss.
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 the extension. However, IndicesOptions as a member variable still seems necessary. There is no way to specify how to handle wild cards appropriately without it, and the SetIndexLifecyclePolicyRequest also uses them. I'm open to suggestions here if this needs changes still.
request.indices(generateRandomStringArray(20, 20, false)); | ||
} | ||
return 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 think we should implement mutateInstance
so the hash code and equals tests can test non-equal instances too?
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 framework changed with the removal the XContent methods. Added tests for equals and hashcode separately since this now extends from ESTestCase.
protected RemoveIndexLifecyclePolicyResponse createTestInstance() { | ||
List<String> failedIndexes = Arrays.asList(generateRandomStringArray(20, 20, false)); | ||
return new RemoveIndexLifecyclePolicyResponse(failedIndexes); | ||
} |
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 we should implement mutateInstance so the hash code and equals tests can test non-equal instances too?
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.
Same as above. The framework changed with the removal the XContent methods. Added tests for equals and hashcode separately.
} | ||
|
||
@Override | ||
public RemoveIndexLifecyclePolicyRequest indices(String... indices) { |
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 the most important thing is for the API to be built in a way where you cannot create invalid requests. It would be good if any mandatory fields in the request were passed into the constructor and don't have setters. The reason this was done for the server side was because the request extends IndicesRequest.Replaceable
but I think in order to achieve the client separation we want we actually can't extend that here?
public XContentBuilder toXContent(XContentBuilder builder, ToXContent.Params params) throws IOException { | ||
builder.startObject(); | ||
builder.field(HAS_FAILURES_FIELD.getPreferredName(), hasFailures()); | ||
builder.field(FAILED_INDEXES_FIELD.getPreferredName(), failedIndexes); |
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.
so this just returns emptyness if there are no failed indexes?
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.
disregard, this should be removed.
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.
} | ||
|
||
@Override | ||
public XContentBuilder toXContent(XContentBuilder builder, ToXContent.Params params) throws IOException { |
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 should not be in the responses. @nik9000 has recently merged some test stuff that will alter your test cases below as well, once this is removed. Pls update to use 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.
Done.
@colings86 @hub-cap Thanks for the first reviews. I think I addressed all the PR comments, and this is ready for another round. |
assertFalse(request.validate().isPresent()); | ||
} | ||
|
||
public void testEqualsAndHashCode() { |
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 we should use EqualsHashCodeTestUtils.checkEqualsAndHashCode()
in this test so we have consistent testing with the rest of the codebase for hashcode and equals?
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. Thanks for pointing out this utility method!
@colings86 Updated the equals and hashcode tests to use the utility method you pointed me at. Thanks for pointing that out. Would you please take another look when you get the chance? |
@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.
@@ -652,6 +653,19 @@ static Request setIndexLifecyclePolicy(SetIndexLifecyclePolicyRequest setPolicyR | |||
return request; | |||
} | |||
|
|||
static Request removeIndexLifecyclePolicy(RemoveIndexLifecyclePolicyRequest setPolicyRequest) { |
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: can we named the variable removeLifecycleRequest
?
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.
Oops! Good catch, 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.
a minor constructor nit, and then one CYA on my part WRT a rename.
private final IndicesOptions indicesOptions; | ||
|
||
public RemoveIndexLifecyclePolicyRequest(List<String> indices) { | ||
if (indices == null) { |
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.
Objects.requireNotNull
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 method also does not need to exist, as you can use this(indices, IndicesOptions.strictExpandOpen())
, and fix the validation in the other constructor.
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.
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.
A++ new constructor code
@@ -343,7 +343,7 @@ static Settings additionalSettings(final Settings settings, final boolean enable | |||
PutLifecycleAction.INSTANCE, | |||
ExplainLifecycleAction.INSTANCE, | |||
SetIndexLifecyclePolicyAction.INSTANCE, | |||
RemovePolicyForIndexAction.INSTANCE, | |||
RemoveIndexLifecyclePolicyAction.INSTANCE, |
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.
Im going to assume all of these changes are approved by someone else :)
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.
Name changes match the changes to SetIndexLifecyclePolicyAction.
@colings86 @gwbrown @hub-cap Thanks for the reviews! |
@jdconrad Thanks for doing this one 😄 |
This change adds the command RemoveIndexLifecyclePolicy to the HLRC. This uses the new TimeRequest as a base class for RemoveIndexLifecyclePolicyRequest on the client side.
This change adds the command RemoveIndexLifecyclePolicy to the HLRC. This uses the new TimeRequest as a base class for RemoveIndexLifecyclePolicyRequest on the client side.