Skip to content
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

HLRC: Add Lifecycle delete to the HLRC #33142

Merged
merged 11 commits into from Aug 29, 2018

Conversation

gwbrown
Copy link
Contributor

@gwbrown gwbrown commented Aug 24, 2018

Adds support for Lifecycle deletion to the Java High-Level Rest Client.
Also includes some stopgap measures to support using the new Client
package structure which should be replaced once the structure
refactoring is complete.

Relates to #33100

Adds support for Lifecycle deletion to the Java High-Level Rest Client.
Also includes some stopgap measures to support using the new Client
package structure which should be replaced once the structure
refactoring is complete.

Relates to elastic#33100
@gwbrown gwbrown added the :Data Management/ILM+SLM Index and Snapshot lifecycle management label Aug 24, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

}

public void testValidate() {
if (frequently()) {
Copy link
Member

Choose a reason for hiding this comment

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

Can you split this into two different tests rather than using the randomness here? I don't think it buys us anything

Copy link
Member

@dakrone dakrone left a comment

Choose a reason for hiding this comment

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

This LGTM assuming @hub-cap is good with the MasterTimeoutRequest change


import java.util.Objects;

public class DeleteLifecycleRequest extends MasterTimeoutRequest<DeleteLifecycleRequest> {
Copy link
Contributor

Choose a reason for hiding this comment

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

The transport based APIs extend AcknowledgedRequest which has a timeout and ackTimeout in addition to the masterNodeTimeout.

(this does not) Curious if is this is intentional ?

The javadoc for AcknowledgedRequest states Facilitates consistency across different api. ... is that something we should carry forward while still divorcing ourselves from the transport request objects ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I based MasterTimeoutRequest on MasterNodeRequest, rather than AcknowledgedRequest, which doesn't have an ackTimeout. It's possible I should be using AcknowledgedRequest instead - the difference wasn't immediately clear.

So, to answer your question: It was intentional, but it's possible I intended the wrong thing.

Copy link
Contributor Author

@gwbrown gwbrown Aug 27, 2018

Choose a reason for hiding this comment

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

I talked to @hub-cap on Slack and his answer was that these timeouts should be based on the parameters that the requests can take. To determine this, there should be a Rest<whatever>Action class which defines those parameters. In this case, RestDeleteLifecycleAction (see here) defines both timeout and master_timeout, so this class should include both.

(Just waiting on some more feedback to make this change)

Copy link
Contributor

Choose a reason for hiding this comment

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

@gwbrown Thanks for following up. I am working a similar issue and will follow your lead here.

@@ -0,0 +1,55 @@
/*
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be DeleteIndexLifecycleRequest ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

From what I saw, the classes with names including IndexLifecycle seem to relate to index<->lifecycle policy relationships (i.e. lifecycle A applies to index B), but ones with just Lifecycle relate to the management of lifecycles. If that's correct, this class is named correctly.

@dakrone, can you confirm?

Copy link
Member

Choose a reason for hiding this comment

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

I think this should be DeleteLifecyclePolicyRequest to indicate that the policy is going to be removed, and then DeleteIndexLifecycleRequest is for when we are removing a lifecycle from an index

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.

I left a couple of minor comments

* @param options the request options (e.g. headers), use {@link RequestOptions#DEFAULT} if nothing needs to be customized
* @param listener the listener to be notified upon request completion
*/
public void deleteLifecycleAsync(DeleteLifecyclePolicyRequest request, RequestOptions options,
Copy link
Contributor

Choose a reason for hiding this comment

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

In the same spirit as @dakrone's comment about renaming the request object to DeleteLifecyclePolicyRequest I think we should rename these methods to deleteLifecyclePolicy and deleteLifecyclePolicyAsync?

@@ -1174,6 +1175,17 @@ static Request xpackUsage(XPackUsageRequest usageRequest) {
return request;
}

static Request deleteLifecycle(DeleteLifecyclePolicyRequest deleteLifecyclePolicyRequest) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Rename to deleteLifecyclePolicy?

Copy link
Member

Choose a reason for hiding this comment

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

Yep, +1 to rename this deleteLifecyclePolicy

@gwbrown
Copy link
Contributor Author

gwbrown commented Aug 28, 2018

Just had a brief meeting with @hub-cap - the result of that meeting is that there are some not-well-understood requirements around exactly which timeouts need to/can be shared between request classes. Baz is going to figure those requirements out when he has bandwidth to do so. In the meantime the abstract request class in this PR will change to include both timeout and master_timeout to allow moving forward with this and other ILM HLRC PR's and we'll consolidate to the final hierarchy later - it ought to be pretty straightforward.

@gwbrown
Copy link
Contributor Author

gwbrown commented Aug 29, 2018

I lied - @hub-cap got the base class into master very quickly (thanks!) so this PR has transitioned to using that base class.

I've made all the changes suggest so far, so any last comments on this? If not I'll merge about EOD (this comment + 7 hours) today, assuming CI passes.

Copy link
Member

@dakrone dakrone left a comment

Choose a reason for hiding this comment

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

I left comments about some renames

@@ -1174,6 +1175,17 @@ static Request xpackUsage(XPackUsageRequest usageRequest) {
return request;
}

static Request deleteLifecycle(DeleteLifecyclePolicyRequest deleteLifecyclePolicyRequest) {
Copy link
Member

Choose a reason for hiding this comment

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

Yep, +1 to rename this deleteLifecyclePolicy

this.lifecycle = lifecycle;
}

public String getLifecycle() {
Copy link
Member

Choose a reason for hiding this comment

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

Can you also rename these getLifecyclePolicy?

try {
DeleteLifecyclePolicyRequest req = new DeleteLifecyclePolicyRequest(randomFrom("", null));
fail("should not be able to create a DeleteLifecyclePolicyRequest with null lifecycle name");
} catch (IllegalArgumentException exception) {
Copy link
Member

Choose a reason for hiding this comment

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

For the future, you can use

expectThrows(IllegalArgumentException.class, () -> new DeleteLifecyclePolicyRequest(randomFrom("", null)));

Instead of having to do the try/fail/catch check

@hub-cap
Copy link
Contributor

hub-cap commented Aug 29, 2018

@gwbrown its also been backported as of about an hour ago. So you should be good to go for any 6.5 merging as well.

Copy link
Member

@dakrone dakrone left a comment

Choose a reason for hiding this comment

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

LGTM

@gwbrown gwbrown merged commit ba8d4eb into elastic:index-lifecycle Aug 29, 2018
gwbrown added a commit that referenced this pull request Aug 29, 2018
Adds support for Lifecycle Policy deletion to the Java High-Level Rest Client.

Relates to #33100
@gwbrown gwbrown deleted the hlrc-delete branch December 7, 2018 04:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Data Management/ILM+SLM Index and Snapshot lifecycle management
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants