relation departure timing changes

[Gustavo Niemeyer]

On Fri, Aug 23, 2013 at 6:30 AM, William Reade
<william.reade at canonical.com> wrote:
> "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.

Sounds fine and adequate to be running the departed hooks on related
units before the broken hook of the departing unit. But that sounds
unrelated to dying, and it also sounds like an interesting
synchronization problem to solve, in the sense that the departing unit
will have to be able to tell when other units are done. That's easy,
conceptually, but corner cases will make it not fun. What's the plan
for establishing that?

> ...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.

Unhelpful but not a problem either, right?

> 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 ;).

I can't quite put my finger on where our misunderstanding is yet, but
we may be close to finding out.


gustavo @ http://niemeyer.net