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
Remove canSetPolicy, canUpdatePolicy, and canRemovePolicy #33037
Remove canSetPolicy, canUpdatePolicy, and canRemovePolicy #33037
Conversation
Since we now store a pre-compiled list of steps for an index's phase in the `PolicyStepsRegistry`, we no longer need to worry about updating policies as any updates won't affect the current phase, and will only be picked up on phase transitions. This also removes the tests that test these methods Relates to elastic#29823
Pinging @elastic/es-core-infra |
if (currentStepKey != null) { | ||
// Check if current step exists in new policy and if not move to | ||
// next available step | ||
StepKey nextValidStepKey = newPolicy.getNextValidStep(currentStepKey); |
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 thinks the getNextValidStep() stuff can go to no?
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.
Can I do that as a followup? I think this change ended up larger than I hoped due to having to change a lot of tests
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.
Sure.
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.
LGTM
* Remove canSetPolicy, canUpdatePolicy and canRemovePolicy Since we now store a pre-compiled list of steps for an index's phase in the `PolicyStepsRegistry`, we no longer need to worry about updating policies as any updates won't affect the current phase, and will only be picked up on phase transitions. This also removes the tests that test these methods Relates to #29823
Since we now store a pre-compiled list of steps for an index's phase in the
PolicyStepsRegistry
, we no longer need to worry about updating policies as anyupdates won't affect the current phase, and will only be picked up on phase
transitions.
This also removes the tests that test these methods
Relates to #29823