Comment 15 for bug 2037120

As it is today, the safest way for me to manage the admin password of databases is:

* To have the leader defining the latest password in an app-scoped secret
* Each unit having a unit-scoped secret with its own currently used admin password

When a new password is set, then the following happens:

1) Leader unit runs the set-password action, generates a new random password and saves it in the app-scoped secret using "secret-set <app-scoped-secret-id>"
2) The app-scoped secret update issues a secret-changed: each unit, including the leader, receives the latest value of the new admin password
3) Each unit loads its own unit-scoped secret, containing the currently working password
4) Each unit unlocks the DB with that password and updates the password of their database
5) Each unit, after confirming the password has been successfully updated, save the new app-scoped password in its own unit-scoped secret

The following secret-remove (app-scoped-secret) is ignored.
The following secret-changed (unit-scoped-secret) should be used to check that unit and app-scoped secrets match (hence, that unit did not lost several updates running before). If they do not match, then run the steps above.
The following secret-remove (unit-scoped-secret) is ignored.

A similar logic would be used in the case of a secret shared across relation to manage the admin password.