relation-get - missing_unit behavior

[Stuart Bishop]

On Tue, Jun 25, 2013 at 11:30 PM, William Reade
<william.reade at canonical.com> wrote:

> Caveat: I haven't actually implemented this myself. It is, however, the sort
> of thing I'd vaguely expect to see a generic implementation of slipping into
> charm-tools, if such a thing hasn't already happened. I'd imagine that you
> are not the first person to encounter this problem, but then I can't
> actually name another example myself...

This is similar to the approach I'd ended up choosing, the main real
difference being that the client relation-joined hook on the master
just updates a list of active client relations stored on the peer
relation, and the peers reach over to the master's client relation
bucket for the relevant credentials.

Here is the relevant comment from my branch discussing the failed
designs and the one that seems to be working:

# Each database unit needs to publish connection details to the
# client. This is problematic, because 1) the user and database are
# only created on the master unit and this is replicated to the
# slave units outside of juju and 2) we have no control over the
# order that units join the relation.
#
# The simplest approach of generating usernames and passwords in
# the master units db-relation-joined hook fails because slave
# units may well have already run their hooks and found no
# connection details to republish. When the master unit publishes
# the connection details it only triggers relation-changed hooks
# on the client units, not the relation-changed hook on other peer
# units.
#
# A more complex approach is for the first database unit that joins
# the relation to generate the usernames and passwords and publish
# this to the relation. Subsequent units can retrieve this
# information and republish it. Of course, the master unit also
# creates the database and users when it joins the relation.
# This approach should work reliably on the server side. However,
# there is a window from when a slave unit joins a client relation
# until the master unit has joined that relation when the
# credentials published by the slave unit are invalid. These
# credentials will only become valid after the master unit has
# actually created the user and database.
#
# The implemented approach is for the master unit's
# db-relation-joined hook to create the user and database and
# publish the connection details, and in addition update a list
# of active relations to the service's peer 'replication' relation.
# After the master unit has updated the peer relationship, the
# slave unit's peer replication-relation-changed hook will
# be triggered and it will have an opportunity to republish the
# connection details. Of course, it may not be able to do so if the
# slave unit's db-relation-joined hook has yet been run, so we must
# also attempt to to republish the connection settings there.
# This way we are guaranteed at least one chance to republish the
# connection details after the database and user have actually been
# created and both the master and slave units have joined the
# relation.
#
# The order of relevant hooks firing may be:
#
# master db-relation-joined (publish)
# slave db-relation-joined (republish)
# slave replication-relation-changed (noop)
#
# slave db-relation-joined (noop)
# master db-relation-joined (publish)
# slave replication-relation-changed (republish)
#
# master db-relation-joined (publish)
# slave replication-relation-changed (noop; slave not yet joined db rel)
# slave db-relation-joined (republish)


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