Adjust testing secret management to be simpler - in particular, to avoid needing to manually manage revisions, which should be transparent to charms.
Rather than Secrets having a dictionary of revision:content-dict, they have two content dictionaries, tracked_content (required) and latest_content (set to the same value as tracked_content if not provided). This matches what charms can see: only either the tracked revision or the latest revision.
A new attribute, removed_secret_revisions is added to Context to track removal of secret revisions in the secret-remove and secret-expired hooks. Calling secret-remove --revision in those hooks must be done, so should be tested, but don't actually change the state that's visible to the charm (for secret-remove the whole point is that the secret revision is no longer visible to anyone, so it should be removed). Tests could mock the secret_remove method, but it seems cleaner to provide a mechanism, given that this should be part of any charm that uses secrets.
Charms should only remove specific revisions in the secret-remove and secret-expired hooks, and only remove the revision that's provided, but it is possible to remove arbitrary revisions. Modelling this is complicated (the state of the Juju secret is a mess afterwards) and it is always a mistake, so rather than trying to make the model fit the bad code, an exception is raised instead.
A warning is logged if a secret revision is created that is the same as the existing revision - in the latest Juju this is a no-op, but in earlier version it's a problem, and either way it's something that the charm should avoid if possible.
Adjust testing secret management to be simpler - in particular, to avoid needing to manually manage revisions, which should be transparent to charms.
Rather than
Secrets having a dictionary of revision:content-dict, they have two content dictionaries,tracked_content(required) andlatest_content(set to the same value astracked_contentif not provided). This matches what charms can see: only either the tracked revision or the latest revision.A new attribute,
removed_secret_revisionsis added toContextto track removal of secret revisions in thesecret-removeandsecret-expiredhooks. Callingsecret-remove --revisionin those hooks must be done, so should be tested, but don't actually change the state that's visible to the charm (forsecret-removethe whole point is that the secret revision is no longer visible to anyone, so it should be removed). Tests could mock thesecret_removemethod, but it seems cleaner to provide a mechanism, given that this should be part of any charm that uses secrets.Charms should only remove specific revisions in the
secret-removeandsecret-expiredhooks, and only remove the revision that's provided, but it is possible to remove arbitrary revisions. Modelling this is complicated (the state of the Juju secret is a mess afterwards) and it is always a mistake, so rather than trying to make the model fit the bad code, an exception is raised instead.A warning is logged if a secret revision is created that is the same as the existing revision - in the latest Juju this is a no-op, but in earlier version it's a problem, and either way it's something that the charm should avoid if possible.