relation departure timing changes

Gustavo Niemeyer gustavo at niemeyer.net
Thu Aug 22 22:25:56 UTC 2013


A dying unit *is* an active unit. The unit becomes dying
instantaneously, so there's no way for it not to be active during some
of the time it is dying, and that's precisely the point of having the
state at all. It allows running polite shutdowns with awareness,
before it becomes fully "dead".

> 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.


On Thu, Aug 22, 2013 at 6:53 PM, Matthew Wedgwood
<matthew.wedgwood at canonical.com> wrote:
> On 08/22/2013 11:57 AM, Gustavo Niemeyer 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.
>>
>
> I can't think of a case where a dying unit should be treated as an active unit, except possibly for cleanup procedures. From the docs[1], "A unit's relation settings persist beyond its own departure from the relation". That implies to me that the unit's relation settings can be queried (for cleanup purposes) even after it departs. 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.
>
> Additionally, I can't think of a case where a "provider" or "consumer" would imply any difference in that regard.
>
>>
>>
>> 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
>>>
>>
>>
>>
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju



-- 

gustavo @ http://niemeyer.net



More information about the Juju mailing list