Backport #21830 to 5.x #21914
Backport #21830 to 5.x #21914
Conversation
…rade & open index (elastic#21830) Today we can easily join a cluster that holds an index we don't support since we currently allow rolling upgrades from 5.x to 6.x. Along the same lines we don't check if we can support an index based on the nodes in the cluster when we open, restore or metadata-upgrade and index. This commit adds additional safety that fails cluster state validation, open, restore and /or upgrade if there is an open index with an incompatible index version created in the cluster. Realtes to elastic#21670
|
+1 to the behavior change, I think prereleases should not be a viable upgrade path. |
|
+1 too |
|
I will merge this in the next 60 min unless anybody objects |
There was a problem hiding this comment.
LGTM. For completeness - we decided to special case 2.0.0 pre-releases because not doing so would mean that a running 5.0 cluster may not accept joins from a 5.1 preventing rolling upgrades. We thought we are better off special casing it in the 5.x series and fully enforce from 6.0 onwards.
👍 |
This is a pretty straight forward backport of #21830 to 5.x but it changes some behavior in BWC.
In 5.x we tested BWC against 2.0.0-RC and it's betas but in master we don't allow this anymore, we only guarantee BWC to GA releases. We also do this for 5.0, 5.0.0-RC1 is not in the list of indices we support. Note: with this PR we actively reject these indices when we see on index / snapshot etc. when we upgrade...
To discuss this change I opened this PR just make everybody aware of this change and with the question if we should do it that way.