Fix min node version before state recovery#86482
Merged
DaveCTurner merged 3 commits intoelastic:masterfrom May 6, 2022
Merged
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
Collaborator
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
Collaborator
|
Hi @DaveCTurner, I've created a changelog YAML for you. |
rjernst
reviewed
May 5, 2022
Member
|
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. |
rjernst
approved these changes
May 5, 2022
Member
rjernst
left a comment
There was a problem hiding this comment.
LGTM. Might be nice to have a test checking a rest handler sees the newly reflected nodes, but it's fine as is too.
Member
Author
|
++ yes it's a |
Member
Author
|
Thanks both :) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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