Repository navigation
Queue a sync when a cluster's controller ID changes to this operator - #3195
Open
omkar619-dev wants to merge 1 commit into
Open
omkar619-dev wants to merge 1 commit into
omkar619-dev wants to merge 1 commit into
Conversation
omkar619-dev
requested review from
FxKu,
Jan-M,
hughcapet,
idanovinda,
jopadi and
mikkeloscar
as code owners
October 2, 2026 17:30
This branch has not been deployed
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
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.
Changing a cluster's
acid.zalan.do/controllerannotation to this operator's ID queues nothing at all, so the cluster is only picked up by the next resync.postgresqlCheckreturns nil whenhasOwnershipfails, andpostgresqlUpdateonly acts when both manifests pass it:On adoption the previous manifest still names the other controller, so
pgOldis nil, there is no else, and the function returns silently.The change
An explicit branch for that case, queueing a sync:
Sync rather than update, and a nil old spec, because this is the shape the surrounding code already uses:
queueClusterEvent's nil-old-spec branch is commented// add, sync,Clone()returns nil for a nil receiver, andpostgresqlAddalready callsqueueClusterEvent(nil, pg, EventAdd). There is also no old spec worth diffing here — the Kubernetes objects may have been created by another operator, so reconciling to the desired state is the only thing that makes sense.This does not close the race @baarde raised on the issue: we cannot know whether the previous operator has finished with the cluster. Resync has exactly the same exposure today, so this narrows the window rather than opening a new one.
Deliberately not included
The mirror case is broken in the same way. When a cluster moves away (
pgOld != nil,pgNew == nil) the missing else means this operator never sees the handover and keeps whatever it had until the next resync. I left it out, because stopping management is a different decision from starting it, andTestPostgresqlUpdateQueuesNothingWhenOwnershipIsLostpins the current behaviour so it reads as a choice rather than an oversight. Happy to handle it here if you would rather the two were symmetric.Tests
Three cases in
postgresql_test.go, with a small helper that sets up a single-worker event queue —initControllerbuilds those in the real operator, but it also reads infrastructure roles and starts the API server.TestPostgresqlUpdateQueuesSyncWhenClusterIsAdoptedasserts oneSYNCevent with a nilOldSpec. Without the branch above it fails withqueued 0, which is the reported symptom.TestPostgresqlUpdateStillQueuesUpdateForOwnedClusterguards the ordinary path, since the new branch adds an early return in front of it.TestPostgresqlUpdateQueuesNothingWhenOwnershipIsLostpins the mirror case described above.go test ./pkg/controller/passes in full, including the pre-existingTestControllerOwnershipOnPostgresql.Closes #3151