Skip to content

Dpe 10203 consumer secret by#1838

Draft
marceloneppel wants to merge 3 commits into
dpe-10203-async-replication-fixesfrom
dpe-10203-consumer-secret-by-id
Draft

Dpe 10203 consumer secret by#1838
marceloneppel wants to merge 3 commits into
dpe-10203-async-replication-fixesfrom
dpe-10203-consumer-secret-by-id

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.

@github-actions github-actions Bot added the Libraries: Out of sync The charm libs used are out-of-sync label Jul 8, 2026
@marceloneppel marceloneppel force-pushed the dpe-10203-async-replication-fixes branch from ef98cd6 to 93e8dce Compare July 8, 2026 18:55
…he consumer

The standby/consumer side read the shared offer secret with a fixed
Juju label, which registers a consumer-side alias under that label.
Juju keeps the alias reserved even after the remote secret is
force-removed during a dead-DC teardown, so a former standby is left
carrying a stale alias it can neither read nor release. The owner-side
OFFER_SECRET_LABEL split already breaks the promotion deadlock, but the
consumer alias remains an avoidable latent hazard whose safe reuse
depends on unverified Juju relabel behaviour.

Referencing the secret purely by the id already published in the
relation databag — as the MySQL async-replication charm does — means no
consumer alias is ever registered and nothing can go stale, closing the
DPE-10203 failure class on the consumer side too. This is backward
compatible: the id is already present in primary-cluster-data and no
peer depends on the alias existing.

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

After a dead-DC teardown the remote app/unit databag on the dying cross-model
async relation raises ModelError ("permission denied") on any read. Only
_get_primary_cluster was guarded; the sibling reads were not, so they crashed the
hooks that keep a promoted cluster reconciling — replication-offer-relation-joined
and database-peers-relation-changed both died, leaving units wedged in error and
blocking re-replication to a fresh cluster.

Route every async-relation databag read through a shared _safe_databag_get helper
(and a shared _remote_unit_addresses for the two identical endpoint list
comprehensions) that treats an unreadable databag as key-absent, matching the
existing _get_primary_cluster behaviour, so the teardown always reconciles instead
of crashing.

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
ops implements Application.planned_units() via the goal-state hook command, which
fails ("saas application ... not found") while a cross-model SAAS force-removed
during a dead-DC teardown still lingers in goal-state. Every caller — the _patroni
property construction, the degraded-status check, the synchronous-node count and the
backups pre-checks — crashed its hook, cascading through the _patroni property to
wedge the promoted cluster and block re-replication to a fresh cluster.

Route them through a single guarded _planned_units property that falls back to the
current unit count when goal-state is unavailable, so hooks reconcile instead of
crashing (DPE-10203 Issue B).

Signed-off-by: Marcelo Henrique Neppel <marcelo.neppel@canonical.com>
@marceloneppel marceloneppel force-pushed the dpe-10203-consumer-secret-by-id branch from 6fc12bd to bb22825 Compare July 8, 2026 19:07
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