Backport of Fix AP upgrade version issue into release/1.17.x #27377
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.
Backport
This PR is auto-generated from #27277 to be assessed for backporting due to the inclusion of the label backport/1.17.x.
The below text is copied from the body of the original PR.
This is a subtle issue introduced by #26449 while fixing a different issue. It only impacts Vault Enterprise but is generally simpler to reason about.
That PR was a correct fix, however the
effectiveSDKVersion
was only ever being set on active nodes not on perf standbys in Enterprise.The big change here is:
SetupCluster
which is necessary on all types of serversRaftBackend.effectiveSDKVersion
back to the binary version so even if we fail to plumb this from core in some edge case in the future it's still the right value in almost all cases (other than testing environments).I've manually tested this locally. To reproduce the issue it fixes you need to:
autopilot_upgrade_version
in config on the new servers (doing so bypasses the bug).In this case you'll see the new servers join but remain "target version" because their Echo's are sending an empty version string. You also see some logs about empty
upgrade_versions
which are legit in this case but are also confusing because you can see them even after the fix due to timing (if AP runs before an Echo has come in but after node joined raft on the leader you'll see that log even on a non-broken cluster and then you don't see a corresponding "OK" log after wards).TODO
Overview of commits