fix: keep aggregator volume order stable to avoid rollout on operator upgrade#260
Merged
Merged
Conversation
… upgrade Signed-off-by: Aleksandr Aleksandrov <aaleksandrov.cy@gmail.com>
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
1 participant
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.
#251 moved the aggregator's
datavolume from the static required-volumes list to a conditional append afterprocfs/sysfs, so for non-persistent aggregators the generated pod template volume order changed from[config, data, procfs, sysfs]to[config, procfs, sysfs, data]. The volume set is identical, but the order change makes a different pod template, so every VectorAggregator and ClusterVectorAggregator with persistence disabled is rolled once when the operator is upgraded.This PR inserts the
datavolume back at its original position (right afterconfig) and adds a regression test pinning the order. Persistent mode is unchanged (the data volume still comes from the StatefulSet volume claim template); volumeMounts order was never affected.Verified with an upgrade test on kind (v1.31.9 and v1.36.1): v0.4.1 operator → this branch over the same CRs — with this fix the aggregator Deployment generation, ReplicaSet and pods stay untouched, config secrets byte-identical; without it the Deployment rolls immediately on operator start.