relation departure timing changes

[Nate Finch]

Seems like we need a third state: "Leaving" - means you shouldn't use the
unit (treat it as dead), but anything required by that unit still counts as
in use and required until it's actually gone.

Gustavo - I think what William means about who connects to whom is who
initiates the connection. When Wordpress connects to MySQL, it is WordPress
that initiates the relationship & thus the connection. WordPress requires
MySQL, but MySQL doesn't care if WordPress exists or not, it just does what
it's told by WordPress (or anyone else).

There way be more symbiotic relationships out there, where both services
"require" each other.... but I think this is what William meant.




On Thu, Aug 22, 2013 at 12:57 PM, Gustavo Niemeyer <gustavo at niemeyer.net>wrote:

> > 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
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130822/c1d9a6d9/attachment.html>