relation departure timing changes

[Gustavo Niemeyer]

> requirers connect to providers and not vice versa.

I'm not sure I understand what that means. A relation is a bilateral
communication channel, and it is entirely valid for a requirer to send
information to a provider. What does it mean for a requirer to
"connect" to a provider and not vice versa?

Although I cannot yet put my finger on a specific reason, I have a bad
feeling about the change suggested. Reporting something as dead while
it is in fact still around doesn't seem great.



On Thu, Aug 22, 2013 at 1:42 PM, William Reade
<william.reade at canonical.com> wrote:
> 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"
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>



-- 

gustavo @ http://niemeyer.net