[DPE-9964] Pre-upgrade switchover to minimize client write downtime during refresh#1650
Draft
taurus-forever wants to merge 2 commits intomainfrom
Draft
[DPE-9964] Pre-upgrade switchover to minimize client write downtime during refresh#1650taurus-forever wants to merge 2 commits intomainfrom
taurus-forever wants to merge 2 commits intomainfrom
Conversation
taurus-forever
changed the title
github-actions
Bot
added
the
Libraries: OK
…uring refresh When the Patroni primary is also the Juju leader (upgraded last), clients lose write access for the entire upgrade cycle because no unit can update the relation endpoints. Perform a graceful Patroni switchover before the snap refresh so the endpoint is updated while the unit is still responsive. Falls back to the current automatic failover behavior if the switchover fails. Also, to commit endpoint to client, charm have to defer upgrade_granted, as Juju batches relation data changes and only commits them when the hook exits. The previous approach updated endpoints inside _on_upgrade_granted but the client wouldn't see the change until after the snap refresh completed — defeating the purpose. Now the switchover + endpoint update happens in the first invocation, which defers the event and returns. Juju commits the endpoint change, the client sees the new primary immediately, and the deferred event fires a second time to proceed with the snap refresh. Skip pre-upgrade switchover for single unit application or when snap revision is unchanged. Assisted-by: Claude:claude-4.6-opus
taurus-forever
force-pushed
the
alutay/dpe9964
branch
from
c75f475 to
e58ff17
Compare
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.
Issue
Primary write endpoint can be temporary outdated for client
applications during the charm upgrade (juju refresh).
Solution
When the Patroni primary is also the Juju leader (upgraded last),
clients lose write access for the entire upgrade cycle because no unit
can update the relation endpoints. Perform a graceful Patroni switchover
before the snap refresh so the endpoint is updated while the unit is
still responsive. Falls back to the current automatic failover behavior
if the switchover fails.
Also, to commit endpoint to client, charm have to defer upgrade_granted, as
Juju batches relation data changes and only commits them when the hook
exits. The previous approach updated endpoints inside _on_upgrade_granted
but the client wouldn't see the change until after the snap refresh
completed — defeating the purpose.
Now the switchover + endpoint update happens in the first invocation,
which defers the event and returns. Juju commits the endpoint change,
the client sees the new primary immediately, and the deferred event
fires a second time to proceed with the snap refresh.
Skip pre-upgrade switchover for single unit application or when snap revision is unchanged.
Assisted-by: Claude:claude-4.6-opus