The percona-cluster charm uses the allowed_units setting on the shared-db interface to notify relations that they are ready to use their mysql credentials by virtue of the fact that their access grants have been configured. Currently this setting is applied by the leader unit but is not propagated to peer units so that they can also set it for their relations. This is not a problem until you delete/remove the leader unit. As of that point units related to the mysql cluster whose db was initialised by that (removed) mysql unit will no longer have allowed_units set anywhere and will likely defer all actions until it is restored (proven with keystone charm) e.g.
* deploy 3 node percona-cluster and keystone
* confirm that allowed_units is present on the shared-db relation
* delete the leader percona unit and add a new unit
* confirm that allowed_units is no longer present on the shared-db relation from any percona unit
I think we should migrate the allowed_units to the leader settings, otherwise we will risk to have yet-another possible *-changed hook spinning issue.
The approach of relation-set for all the peers in case the leader unit goes away is what leader-
allowed_units is read via leader-get, and the relation-set -r xxx:n allowed_units=... just to notify the other side of shared-db that the database is ready to be consumed.