Guarantee order of relation-joined & relation-changed?

[Clint Byrum]

Excerpts from Gustavo Niemeyer's message of 2013-07-04 06:28:36 -0700:
> On Thu, Jul 4, 2013 at 8:59 AM, Stuart Bishop
> <stuart.bishop at canonical.com> wrote:
> (...)
> > Is this problem valid, or is there something already preventing this race?
> 
> There's no race in the traditional sense of the term. Whatever the
> ordering, the system communicates any changes to remote units so they
> get notified of the new state.
> 
> Andreas is also right that different situations will have a different
> orderings that are most convenient.
> 
> We talked about ordering before in a different context, for example:
> 
> https://lists.ubuntu.com/archives/juju/2012-February/001259.html
> 

Note that I suggested one can handle this in helpers here:

https://lists.ubuntu.com/archives/juju/2012-February/001260.html

Basically what needs to happen in the cited postgres example is that
one needs to defer a relation-set until the necessary state has been
reached. Something like this:

You need a callback:
--- begin set-pgsql-credentials ---
#!/bin/sh
STATE=$(check_or_assert_state)
if [ "$STATE" != "desired_state" ] ; then
    exec helper not-ready
fi
helper set-deferred-values
--- end set-pgsql-credentials ---

Then in the client relationship setup scripts:
# After relation-joined/changed has done whatever it can do no matter the state..
helper relation-defer set-pgsql-credentials user=foo pass=baz host=xxxx

Then in every other hook you need to do run the event loop:

helper run-defer

Of course, these tools would be _much_ better done inside juju. Ideally
one would note what relations depend on others in the charm and then
juju would just run this event loop appropriately.