Guarantee order of relation-joined & relation-changed?

[Stuart Bishop]

A fix has been submitted for the PostgreSQL charm, and I suspect all
databases will have a similar issue. If a new unit is added to a
client service related to a database service, the new client units
relation-joined and relation-changed hooks may run before the database
service's relation-changed hook. Because the relationship was already
setup and functioning, the authentication credentials are already
present in the database unit's relation storage. If the new client
unit's hooks happen to be run before the database unit's hooks, then
the client will find and attempt to use these authentication
credentials. This will fail because the server has yet to grant access
to the new client unit's IP address.

One alternative would be to disable IP access controls, but that would
not be accessible at many sites. The proposed fix is to add a new
setting to the relation, informing the clients what units have been
authorized. This makes it more complex to use the service. It is
trivial to add the logic to a client charm, but I suspect it will
often be ignored leading to flaky client charms.

This would not be a problem if we guaranteed that the new unit's
relation-changed hook will not be fired until existing unit's
relation-changed hooks have succeeded.

Is this problem valid, or is there something already preventing this race?

Should we implement this guarantee?


-- 
Stuart Bishop <stuart.bishop at canonical.com>