DPE-4235, DPE-3262, DPE-4315 Common UX for replication #452
Conversation
paulomach
requested review from
shayancanonical,
carlcsaposs-canonical and
taurus-forever
paulomach
changed the title
…pe-4235-redo-relation-after-switchover
paulomach
changed the title
| def _on_secret_change(self, event: SecretChangedEvent): | ||
| """Propagates the secret being changed.""" |
There was a problem hiding this comment.
question: does each juju application have its own secret? is it possible for them to all share the same secret (so that it only needs to be managed by the primary charm)?
There was a problem hiding this comment.
yes.
It should but that add extra complexity since we always deploy an app with it own secrets, so unifying old need to delete one, and recreating on relation broken.
giving the troubled history with secrets and CMR, I rather do some duplication that works for now.
There was a problem hiding this comment.
giving the troubled history with secrets and CMR, I rather do some duplication that works for now.
👍
asking just for my understanding: not sure I understand—during primary switchover there's no way to transfer ownership of the secret to the new app?
There was a problem hiding this comment.
It can't. Juju design it thinking in a saas model, where a service is provider. In practice the relation offer side is the only one that can manipulate the secret granted to the relation. The consumer side can neither write nor grant a secret to the relation.
There was a problem hiding this comment.
okay; then probably never a good idea to use a single secret
thank you!
Issue
Solution
async-primarywhen creating the async relation.Fixes #445