relation departure timing changes

[Gustavo Niemeyer]

On Fri, Aug 23, 2013 at 12:32 PM, William Reade
<william.reade at canonical.com> wrote:
> True -- but I don't think the macro effects can actually be distinguished.
> Until the mooted second stage, the effect of a dying *relation* will stay
> the same: all units just run for the exit without paying any attention to
> each other :).

It's not clear what is implied in that, so I'm sorry if that sounds
repetitive: if we're improving the termination of relations, we ought
to be doing it both if a unit is dying or if a relation is dying,
rather than special casing one of them. Charm authors shouldn't have
to take into account which of the two cases they're designing for,
because it's the same operation.

> I agree; the impact on a well-written charm, that is already prepared for
> possible silent breakage of related units at any time, will be nil; but even
> a perfect and complete implementation of everything discussed here will not
> free charms from that responsibility. I don't think that's *in itself* a
> strong argument against making a minor change that moves us a step towards a
> clearer model; but I agree that it would be deeply unhelpful to misrepresent
> the guarantees we do make even by implication. I think that's about
> messaging, not about implementation, though.
(...)
> Part of what we're doing here is deciding whether it's worth investing in,
> which will then feed into the question of when :).

If the way it will work is "whether stuff runs or not is sheer luck",
then there's IMO no point in spending any time on this at all, and the
messaging should be "this is how it works; deal with it".

If, on the other hand, we're spending time on this, we should do
better than sheer luck, so the message can be "in those circumstances,
the hooks run".

(...)
> 1) peers notify peers of their own imminent departure as soon as they're
> aware of it
(...)
> 3) providers notify requirers of their own imminent departure as soon as
> they're aware of it
(...)
> It would be extremely cheap to implement (1) and (3) today, but that work
> would not allow us to guarantee any new properties about the system.

Yes, but these offer zero gain if the guy on the other end is gone by
the time the notifications arrive.

> There are legitimate concerns that, in the absence of extremely clear
> messaging, implementing (1) and (3) alone may lead charmers to infer the
> existence of guarantees that do not in fact exist.

Exactly.


gustavo @ http://niemeyer.net