Skip to content

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

Merged
merged 12 commits into from
Oct 16, 2018
Merged

Conversation

jdconrad
Copy link
Contributor

@jdconrad jdconrad commented Oct 1, 2018

This change adds the command RemoveIndexLifecyclePolicy to the HLRC. This uses the new TimeRequest as a base class for RemoveIndexLifecyclePolicyRequest on the client side.

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

}

@Override
public RemoveIndexLifecyclePolicyRequest indices(String... indices) {
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor Author

@jdconrad jdconrad Oct 3, 2018

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;
}
Copy link
Contributor

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?

Copy link
Contributor Author

@jdconrad jdconrad Oct 3, 2018

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);
}
Copy link
Contributor

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?

Copy link
Contributor Author

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) {
Copy link
Contributor

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);
Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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 {
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@jdconrad
Copy link
Contributor Author

jdconrad commented Oct 3, 2018

@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() {
Copy link
Contributor

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?

Copy link
Contributor Author

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!

@jdconrad
Copy link
Contributor Author

jdconrad commented Oct 4, 2018

@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?

@jdconrad
Copy link
Contributor Author

jdconrad commented Oct 4, 2018

@elasticmachine test this please

Copy link
Contributor

@colings86 colings86 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jdconrad I left a nit comment but this LGTM. I would like @hub-cap or @gwbrown to take a look before we merge it as they are more familiar with the HLRC itself.

@@ -652,6 +653,19 @@ static Request setIndexLifecyclePolicy(SetIndexLifecyclePolicyRequest setPolicyR
return request;
}

static Request removeIndexLifecyclePolicy(RemoveIndexLifecyclePolicyRequest setPolicyRequest) {
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops! Good catch, thanks.

Copy link
Contributor

@hub-cap hub-cap left a 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. :shipit:

private final IndicesOptions indicesOptions;

public RemoveIndexLifecyclePolicyRequest(List<String> indices) {
if (indices == null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Objects.requireNotNull

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Copy link
Contributor

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,
Copy link
Contributor

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 :)

Copy link
Contributor Author

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.

@jdconrad jdconrad merged commit 80474e1 into elastic:index-lifecycle Oct 16, 2018
@jdconrad
Copy link
Contributor Author

@colings86 @gwbrown @hub-cap Thanks for the reviews!

@colings86
Copy link
Contributor

@jdconrad Thanks for doing this one 😄

jdconrad added a commit that referenced this pull request Oct 16, 2018
This change adds the command RemoveIndexLifecyclePolicy to the HLRC. This uses the
new TimeRequest as a base class for RemoveIndexLifecyclePolicyRequest on the client side.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants