-
Notifications
You must be signed in to change notification settings - Fork 25.7k
[ML] Making indices/aliases hidden takes a while after cluster startup #93148
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
[ML] Making indices/aliases hidden takes a while after cluster startup #93148
Conversation
When a cluster is upgraded from a version that didn't have hidden indices/aliases to one that does, we make the relevant ML indices and aliases hidden. However, the steps to do this are split over 5 actions that run sequentially, so the work might take a second or two after the upgraded cluster starts up. This can cause the test that asserts on the final state to fail if it runs very quickly after the upgraded cluster startup. The solution is to retry the test for a few seconds to give a chance for all the upgrade actions to complete. Relates elastic#93062
|
Pinging @elastic/ml-core (Team:ML) |
| // The 5 operations in MlInitializationService.makeMlInternalIndicesHidden() run sequentially, so might | ||
| // not all be finished when this test runs. The desired state should exist within a few seconds of startup, | ||
| // hence the assertBusy(). | ||
| assertBusy(() -> { |
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.
All the changes apart from the comment and the assertBusy() are just auto-formatting changes.
przemekwitek
left a comment
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
💔 Backport failed
You can use sqren/backport to manually backport by running |
elastic#93148) When a cluster is upgraded from a version that didn't have hidden indices/aliases to one that does, we make the relevant ML indices and aliases hidden. However, the steps to do this are split over 5 actions that run sequentially, so the work might take a second or two after the upgraded cluster starts up. This can cause the test that asserts on the final state to fail if it runs very quickly after the upgraded cluster startup. The solution is to retry the test for a few seconds to give a chance for all the upgrade actions to complete. Relates elastic#93062
#93148) (#93149) When a cluster is upgraded from a version that didn't have hidden indices/aliases to one that does, we make the relevant ML indices and aliases hidden. However, the steps to do this are split over 5 actions that run sequentially, so the work might take a second or two after the upgraded cluster starts up. This can cause the test that asserts on the final state to fail if it runs very quickly after the upgraded cluster startup. The solution is to retry the test for a few seconds to give a chance for all the upgrade actions to complete. Relates #93062
|
It turns out this test and the related code isn't in 7.17, due to #53674 (comment). So this doesn't need backporting to 7.17 after all. |
When a cluster is upgraded from a version that didn't have hidden indices/aliases to one that does, we make the relevant ML indices and aliases hidden. However, the steps to do this are split over 5 actions that run sequentially, so the work might take a second or two after the upgraded cluster starts up. This can cause the test that asserts on the final state to fail if it runs very quickly after the upgraded cluster startup. The solution is to retry the test for a few seconds to give a chance for all the upgrade actions to complete.
Relates #93062