Comment 11 for bug 2037120

To clarify a point in your comment:

"--refresh should jump all the revisions to the latest value"....

Are you proposing that the leader runs "secret-get --refresh", then that updates the tracked revision for *all* peer units? All peer units track the same revision number, and the leader, via --refresh, can update the tracked revision to the latest for all units? And each unit can use --peek if it wants to see the latest? Does your scenario 2 below contradict that? Or at least indicate a unit owned secret should be used in that case?

With your scenario 1, the current behaviour still supports that - if an error occurs in the hook generating a new rev (rev 2 in your example), no secret changed hook is fired.

With your scenario 2, that can indeed happen if a unit agent is down when the rev 2 changed hook is fired, and then it wakes up before the changed hook for rev 3 is fired, so it sees that rev 3 when it does a secret-get. If you want that unit to still access the v1 it last used, then that means that we do indeed want each peer unit to individually track their own revision; the notion that all peer units see the same revision is then not what we would want. But, if we want each unit to track a secret separately, then that suggests we'd use a unit owned secret, not an app owned one. So, we come back to for app owned secrets, all peer units track the same revision, and only the leader can do a --refresh to update the pointer. The leader is responsible for using the secret changed event to --peek at the latest revision to update the workload. If successful, it does a --refresh to expose that new revision to all other peer units next time they do a secret-get; unit that time, the other peers still see the old revision. Am I interpreting your intent correctly?