relation departure timing changes

William Reade william.reade at canonical.com
Thu Aug 22 16:42:08 UTC 2013


Hi all

This is inspired by the "relation-list reporting dying units" bug [0],
which can be reasonably simply fixed by reporting peer units' departure
from a relation as soon as we know that they're being destroyed (rather
than *after* the unit has handled the departure as we currently do [1]).

I'm not aware of any reason this measure might be controversial (please let
me know if you are); but it raises an interesting question whose answer
hinges on common practice across the charm community. So far, there has
been no practical distinction between relation providers and requirers;
we're considering introducing an asymetry in the relationship, such that
providers signal departure early as above (but requirers continue to signal
departure only once they have actually departed).

This makes intuitive sense given the names of the roles; but it only makes
practical sense if requirers and providers are written such that,
essentially, requirers connect to providers and not vice versa. Many charms
certainly do work this way, and would thus benefit from such a change; but
it's hard to audit this behaviour across the charm ecosystem. However, I'd
like to know if anyone is aware which charms (or, most likely, entire
interfaces) would *not* work correctly if we were to introduce this
behaviour; this will help us figure out if, when, and how to do so.

Cheers
William


[0] https://bugs.launchpad.net/juju-core/+bug/1192433

[1] https://juju.ubuntu.com/docs/authors-charms-in-action.html --
"Departing relations"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130822/7603cdde/attachment.html>


More information about the Juju mailing list