This change will store the vault kv secret id in relation and make sure that the secret is only fetched using that Id to be ensure that the ID format does not change over time not even when the relation is removed then added again.
The optimal solution would be to remove the secret when the relation is removed so a new secret is created if that relation is added again. This solution is not straightforward as it requires the charm to know the label of the secret it wants to remove, that will only be possible if it is passed by the lib as in #263 example pr. However as explained the description of that PR this makes the lib tied to some implementation detail it should not be concerned with. A ticket has been created in the backlog to simplify juju secret labels in the charm which should make it much easier to remove the secret on relation-broken events.
saltiyazan
commented
2 months ago
Description
This change will store the vault kv secret id in relation and make sure that the secret is only fetched using that Id to be ensure that the ID format does not change over time not even when the relation is removed then added again.
The optimal solution would be to remove the secret when the relation is removed so a new secret is created if that relation is added again. This solution is not straightforward as it requires the charm to know the label of the secret it wants to remove, that will only be possible if it is passed by the lib as in #263 example pr. However as explained the description of that PR this makes the lib tied to some implementation detail it should not be concerned with. A ticket has been created in the backlog to simplify juju secret labels in the charm which should make it much easier to remove the secret on relation-broken events.
Checklist: