On Fri, Aug 23, 2013 at 11:06 AM, Gustavo Niemeyer <[email protected]>wrote:
> On Fri, Aug 23, 2013 at 6:30 AM, William Reade > <[email protected]> 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
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
