Skip to content

Fix/standby backup guard async repl 16#1588

Draft
marceloneppel wants to merge 5 commits into
16/edgefrom
fix/standby-backup-guard-async-repl-16
Draft

Fix/standby backup guard async repl 16#1588
marceloneppel wants to merge 5 commits into
16/edgefrom
fix/standby-backup-guard-async-repl-16

Conversation

@marceloneppel

Copy link
Copy Markdown
Member

Issue

Solution

Checklist

  • I have added or updated any relevant documentation.
  • I have cleaned any remaining cloud resources from my accounts.

create-backup and list-backups cannot succeed on a standby cluster, whose
data is managed by replication from the primary, but they were not stopped
up front — users hit confusing late failures instead of being told to run
on the primary. Reject them early when the unit belongs to a standby
cluster. The check keys on the promoted cluster, not merely the presence
of a replication relation, so the primary still backs up while replication
is active; restore stays blocked on any replicating cluster, unchanged.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
…e units

During async replication setup the relation can briefly exist with no
remote units published. In that window, re-emitting the relation-changed
event raised StopIteration and cluster promotion could act on a missing
relation, crashing the hook. Guard both paths so these transient states
are handled instead of erroring.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
Add end-to-end coverage that a standby cluster rejects backup actions
while the primary still backs up, against Ceph-backed S3. The microceph
host IP now uses a non-loopback address so the RGW endpoint is reachable
from workloads.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
…-guard-async-repl-16

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
@github-actions github-actions Bot added the Libraries: Out of sync The charm libs used are out-of-sync label Jun 12, 2026
The 600s wait for the second cluster's s3-integrator to reach blocked
status times out on the resource-constrained arm64 CI runner (two
3-unit clusters plus microceph contend for ~16GB), while the same test
passes on amd64. Raise this wait to 15 minutes — it is the shortest
wait in the test, the others already allow 20-30 minutes.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Libraries: Out of sync The charm libs used are out-of-sync

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant