Closed juditnovak closed 7 months ago
Implementing Peer Relations data abstraction and data interaction as the exact same like what we have for Cross-charm relations.
The proposal is FULLY re-using already existing code (behavior) set for Cross-charm Relations.
There are 3 Peer-specific requirements (how it's been implemented in the charms) that are taken over here:
Rolling upgrades
If only databag was used (i.e. Internal Secrets in plain text) -> We move secrets one-by-one to a Juju Secret whenever the secret field is referred to
If the charm was already using secrets BUT not by labels but URI -> We remove the URI from the databag and stick a label on the secret
Protection against old bugs (i.e. versions compatibilty):
"deleted label": Soft delete, i.e. if a secret is to be removed, we just replace the value with a specific label
Implementing Peer Relations data abstraction and data interaction as the exact same like what we have for Cross-charm relations.
The proposal is FULLY re-using already existing code (behavior) set for Cross-charm Relations.
There are 3 Peer-specific requirements (how it's been implemented in the charms) that are taken over here:
Rolling upgrades
If only databag was used (i.e. Internal Secrets in plain text) -> We move secrets one-by-one to a Juju Secret whenever the secret field is referred to
If the charm was already using secrets BUT not by labels but URI -> We remove the URI from the databag and stick a label on the secret
Protection against old bugs (i.e. versions compatibilty):
"deleted label": Soft delete, i.e. if a secret is to be removed, we just replace the value with a specific label