relation departure timing changes

[William Reade]

> > As discussed in the bug[0], it makes sense to me that dying units should
> depart as soon
> > as they know that they're being destroyed.
>
> Definitely in agreement. The question is simply what "the unit should
> depart" means. What raised by eyebrows was the side effects mentioned
> in this thread, which I still don't understand.
>

"The unit should depart" means that related units should start running the
-departed hook for that unit. At the moment, related units will only run
those hooks after the dying unit has run its -broken hook, and that means
that there is *always* a window, after the dying unit has torn down any
relation state, in which all related units still believe it to be active.

The question is "when does this matter". My contention is that:

 * it's a problem for units in peer relations, which want as much warning
as possible to reconfigure, as described in the bug
 * it's a problem for units that "require" the units on the other side of a
relation, which also want to reconfigure before their dependencies disappear
 * it's *not* a problem for units that merely "provide" a service to units
on the other side of a relation, because (while they may well want to
reconfigure by revoking access for the dying unit) their operation should
not be materially affected by the disappearance of a dying requirer unit

...but the problem is that, even if everyone agrees with the above, any
potential existing relations that *don't* follow the assumed model of
providers/requirers will find such a change unhelpful.

Perhaps I'm conflating two problems -- that of determining the *ideal*
behaviour around departure synchronization, and that of determining the
best *practical* behaviour given the implicit constraints in the existing
charm ecosystem -- but I think we need to consider the two issues together
lest we do something entirely crazy ;).

Cheers
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130823/89583627/attachment-0001.html>