secret-set creates a new revision when the contents are unchanged
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Canonical Juju |
Fix Committed
|
High
|
Ian Booth | ||
Bug Description
Calling secret-set with the same contents as the latest revision creates a new revision. For example:
```shell
$ juju exec -u dummycharm/0 secret-add sssssh=nottelling
secret:
$ juju secrets
ID Name Owner Rotation Revision Last updated
cpl69kfmp25c76i
$ juju exec -u uptime/0 secret-set secret:
$ juju exec -u uptime/0 secret-set secret:
$ juju secrets
ID Name Owner Rotation Revision Last updated
cpl69kfmp25c76i
```
This is understandable because the controller doesn't know what the content is. Charm code should also be written such that content is only set when the charm knows that the content has been updated.
However, we have found that it is easy for charmers to run afoul of this behaviour, and inadvertently create huge numbers of revisions (that then cause performances issues with Juju, particularly if they are also not properly removed).
It would nicer if `secret-set` was idempotent (as other hook tools are).
This would be better achieved in Juju than in ops, because Juju could (for example) keep a hash of the secret content to determine whether it has changed, whereas ops would have to always request the content in order to know if it has changed.
| tags: | added: secrets |
| Changed in juju: | |
| milestone: | none → 3.6-beta2 |
| assignee: | nobody → Ian Booth (wallyworld) |
| importance: | Undecided → High |
| status: | New → In Progress |
| Changed in juju: | |
| status: | In Progress → Fix Committed |
| Ben Hoyt (benhoyt) wrote | #1 |
Fix PR, for reference: https:/