relation departure timing changes

William Reade william.reade at canonical.com
Fri Aug 23 11:19:16 UTC 2013


On Fri, Aug 23, 2013 at 11:06 AM, Gustavo Niemeyer <gustavo at niemeyer.net>wrote:

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

<unit dying> is just the point at which it's sane/safe to inform related
units that the dying unit *will* be going away. It's not related otherwise;
there's no requirement that we pollute the scope mechanism by taking
lifecycle into account directly. I'm not currently proposing that the
servers wait for the clients; just that the clients' window of opportunity
for clean reconfiguration be somewhat widened from "zero" to "sometimes
greater than zero".

Causing servers to wait for clients *would* be useful, but you're right:
it's not a problem we can solve correctly today. But... are you thinking of
corner cases beyond the "missing unit" problem? I haven't spotted any
myself, and would be most grateful if you'd point out any holes in my
thinking there; my current opinion is that (1) we need --force anyway, but
haven't been able to schedule it yet and (2) clear user demand for a
cleaner global teardown sequence would help us to do so.

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

Well, that's what I'm trying to discover. It breaks an existing and
documented guarantee that I *think* is itself unhelpful; but that's only
true if charmers have interpreted provider/requirer as I do. I do think
it's a good change to make, but I don't think it's sensible for us to do so
without some degree of consultation.


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

.Yeah, we're making progress :).

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


More information about the Juju mailing list