Skip to content

Conversation

@gwbrown
Copy link
Contributor

@gwbrown gwbrown commented Oct 1, 2018

When an index is configured to use a lifecycle policy that does not
exist, this will now be noted in the step_info for that policy.

Contrary to what's noted in the associated issue (#33074), this does
not move the index to the Error step, and instead sets the step_info
with a note that the policy does not exist. This prevents issues with
recovering from this state.

Resolves #33074

When an index is configured to use a lifecycle policy that does not
exist, this will now be noted in the step_info for that policy.
@gwbrown gwbrown added the :Data Management/ILM+SLM Index and Snapshot lifecycle management label Oct 1, 2018
@gwbrown gwbrown requested review from colings86 and dakrone October 1, 2018 22:28
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

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 a couple of comments and a question

+ "] with policy [" + policy + "] is not recognized");
return;
if (stepRegistry.policyExists(policy) == false) {
logger.trace("policy [{}] for index [{}] does not exist, recording this in step_info for this index",
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 at debug level

new StepInfoExceptionWrapper(new IllegalArgumentException("policy [" + policy + "] does not exist")));
return;
} else {
logger.error("current step [" + getCurrentStepKey(lifecycleState) + "] for index [" + indexMetaData.getIndex().getName()
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 change this to use parameterized logging?

if (o == null || getClass() != o.getClass()) return false;
StepInfoExceptionWrapper that = (StepInfoExceptionWrapper) o;
return Objects.equals(exception.getMessage(), that.exception.getMessage())
&& Objects.equals(exception.getClass(), that.exception.getClass());
Copy link
Member

Choose a reason for hiding this comment

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

Is there a reason we shouldn't do Objects.equals(exception, that.exception)? Do we want to have exceptions with different stacktraces be considered the same?

Copy link
Contributor Author

@gwbrown gwbrown Oct 1, 2018

Choose a reason for hiding this comment

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

I went back and forth on this too, but there's two things:

  1. This is for serializing to step_info, and only the exception type and message get into the serialized version, so you can argue that it makes sense to check those here.
  2. If we just check equality of the exception here, then do you know of a good way to get this test working?

I'd be delighted to go with a different approach here, I don't really like this class if I'm being honest. Do you have a recommendation for a different way to approach this?

Copy link
Contributor

Choose a reason for hiding this comment

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

One option might be for this class to hold the already serialised form of the exception, but I'm not sure if that is better or worse than the current solution

@gwbrown
Copy link
Contributor Author

gwbrown commented Oct 2, 2018

I've addressed most of the comments and will explore some alternative solutions to replace StepInfoExceptionWrapper today.

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.

LGTM

@gwbrown gwbrown merged commit 13d8929 into elastic:index-lifecycle Oct 4, 2018
gwbrown added a commit that referenced this pull request Oct 4, 2018
When an index is configured to use a lifecycle policy that does not
exist, this will now be noted in the step_info for that policy.
@gwbrown gwbrown deleted the ilm/nonexistent-policy branch December 7, 2018 04:58
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.

4 participants