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

Add min_* conditions to rollover #83345

Merged
merged 59 commits into from
Jul 26, 2022
Merged

Add min_* conditions to rollover #83345

merged 59 commits into from
Jul 26, 2022

Conversation

probakowski
Copy link
Contributor

@probakowski probakowski commented Feb 1, 2022

This change adds min_age, min_size, min_docs, min_primary_shard_size, and min_primary_shard_docs to the rollover API and ILM rollover action.

Logic for determining if rollover should proceed:

  • as before, if there are no conditions, then proceed (this is a command to rollover, it's unconditional)
  • if any conditions are specified, then all min_* conditions must be met (AND logic) and at least one max_* condition must be met (OR logic, the same as currently implemented).

Note that the above means that if you were to define only min_* conditions it will never rollover (since at least one max_ condition is required), therefore we validate for this explicitly in the ILM rollover action, as well as on the on rollover API itself.

@probakowski
Copy link
Contributor Author

@elasticsearchmachine run elasticsearch-ci/part-2 (failure unrelated, fixed by #83348)

@mark-vieira mark-vieira added v8.2.0 and removed v8.1.0 labels Feb 2, 2022
@probakowski probakowski added :Data Management/ILM+SLM Index and Snapshot lifecycle management >enhancement labels Feb 24, 2022
@joegallo joegallo requested a review from dakrone July 22, 2022 17:38
joegallo added 2 commits July 22, 2022 14:49
Unlike with an ILM rollover action, a max_* condition is not strictly
required -- an unconditional rollover is valid.

However, if any conditions are present, then at least one of them must
be a max_* condition.
@joegallo
Copy link
Contributor

I added the validation change that we discussed, @dakrone -- see 6658822. I've also updated the description.

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 generally looks good! I left a few minor comments about BWC, serialization, and the like.

@@ -67,6 +67,10 @@ public String name() {
return name;
}

public boolean isRequired() {
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 add javadocs for what this method is used for?

Copy link
Member

Choose a reason for hiding this comment

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

I also think it's kind of a difficult/confusing name, perhaps "requiresAdditionalConditions" or "requiresMaxCondition" instead?

Copy link
Contributor

Choose a reason for hiding this comment

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

How about inverting this -- rather than a boolean method that says "here's meaning" how about returning an Enum for "here's what this is"? That is, something like Condition.Type.MIN and Condition.Type.MAX.

We care about this in two places -- validate() (has to have at least one MAX), and also when evaluating areConditionsMet (all MIN conditions and at least one MAX condition must be 'met'). It seems like both those cases would read clearer if they just were what they said, rather than abstracting away behind some boolean method.

It'd be more direct, but it would also be tighter binding. That said, though, I don't see any reason we couldn't revisit that in the future if some third kind of condition or new rules, etc, were added.

Copy link
Member

Choose a reason for hiding this comment

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

That would be totally okay with me too, my main concern is that from the name alone, there is no way to tell what this actually signifies, or how it is used. Returning a condition type would work for differentiating both of those, so that works for me.

Copy link
Contributor

Choose a reason for hiding this comment

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

👍, 8a60331

@elasticsearchmachine elasticsearchmachine changed the base branch from master to main July 22, 2022 23:09
@joegallo joegallo requested a review from dakrone July 26, 2022 00:21
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, thanks for getting this in!

@joegallo joegallo merged commit 539434d into elastic:main Jul 26, 2022
joegallo added a commit that referenced this pull request Jul 26, 2022
@elasticsearchmachine
Copy link
Collaborator

@joegallo according to this PR's labels, I need to update the changelog YAML, but I can't because the PR is closed. Please either update the changelog yourself on the appropriate branch, or adjust the labels. Specifically:

  • The PR is labelled release highlight but the changelog has no highlight section

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 >enhancement release highlight Team:Data Management Meta label for data/management team v8.4.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants