Unsupported upgrades from 7.nonlast to 8.x are still permitted #81865
Assignees
Labels
>bug
:Core/Infra/Core
Core issues without another label
Team:Core/Infra
Meta label for core/infra team
Comments
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
grcevski
pushed a commit
to grcevski/elasticsearch
that referenced
this issue
Jan 6, 2022
This PR introduces a check to prevent upgrading to 8.0 without first upgrading to 7.last. Closes elastic#81865
grcevski
added a commit
that referenced
this issue
Jan 14, 2022
* Prevent upgrades to 8.0 from 7.non-last This PR introduces a check to prevent upgrading to 8.0 without first upgrading to 7.last. Closes #81865 Co-authored-by: David Turner <[email protected]>
grcevski
added a commit
to grcevski/elasticsearch
that referenced
this issue
Jan 14, 2022
* Prevent upgrades to 8.0 from 7.non-last This PR introduces a check to prevent upgrading to 8.0 without first upgrading to 7.last. Closes elastic#81865 Co-authored-by: David Turner <[email protected]>
grcevski
added a commit
that referenced
this issue
Jan 14, 2022
This PR introduces a check to prevent upgrading to 8.0 without first upgrading to 7.last. Closes #81865 Co-authored-by: David Turner <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Upgrading to the next major version with a rolling restart requires upgrading to the last minor of the previous major first. However you could upgrade from 5.x to 6.x and from 6.x to 7.x via a full cluster restart without upgrading to 5.last (respectively 6.last) first.
For 8.x we will impose the same restriction on both upgrade paths: they must always go via 7.last. This will ensure that folks are notified about all deprecations and other changes before starting the major upgrade.
We should prevent users from inadvertently doing an unsupported upgrade from 7.15 or earlier to 8.x by bailing out if the on-disk node version is too old. It should be ok to let users explicitly bypass this restriction by running
elasticsearch-node override-version, but we want this to be an explicit action with a disclaimer and an acknowledgement from the user, rather than something that just silently appears to work./cc @skearns64
Relates #81862
The text was updated successfully, but these errors were encountered: