-
Notifications
You must be signed in to change notification settings - Fork 25.1k
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
Fix min node version before state recovery #86482
Fix min node version before state recovery #86482
Conversation
We use the minimum node version in the cluster state to make decisions about backwards compatibility (e.g. to choose newer actions in the REST layer only if all nodes will support it). Once the cluster is fully formed we reject attempts by older nodes to join the cluster so that the minimum node version only ever increases, which makes backwards-compatibility decisions safe. However, it's possible that the REST layer will make decisions about backwards compatibility before the cluster is fully formed. In this state, older nodes may still join the cluster and may therefore see actions that they do not understand. With this commit we report no nodes to the REST layer until the cluster is fully-formed, and change the minimum node version in an empty cluster to be the minimum compatible version. This means the REST layer will operate in a maximally-compatible mode until the cluster is formed. Relates elastic#86405
Pinging @elastic/es-core-infra (Team:Core/Infra) |
Hi @DaveCTurner, I've created a changelog YAML for you. |
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 like the idea here! However, how would the nodes passed to the initRestHandlers ever get updated once the cluster state has stabilized on the new ES version? This happens only once when starting up the node.
Oh I see, we pass a supplier around everywhere, so once the cluster state gets updated locally, the next call to any rest handler using it will see the new nodes. |
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. Might be nice to have a test checking a rest handler sees the newly reflected nodes, but it's fine as is too.
++ yes it's a |
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! Thank you!
Thanks both :) |
We use the minimum node version in the cluster state to make decisions
about backwards compatibility (e.g. to choose newer actions in the REST
layer only if all nodes will support it). Once the cluster is fully
formed we reject attempts by older nodes to join the cluster so that the
minimum node version only ever increases, which makes
backwards-compatibility decisions safe.
However, it's possible that the REST layer will make decisions about
backwards compatibility before the cluster is fully formed. In this
state, older nodes may still join the cluster and may therefore see
actions that they do not understand.
With this commit we report no nodes to the REST layer until the cluster
is fully-formed, and change the minimum node version in an empty cluster
to be the minimum compatible version. This means the REST layer will
operate in a maximally-compatible mode until the cluster is formed.
Relates #86405