> > 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
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
