relation departure timing changes

[William Reade]

On Fri, Aug 23, 2013 at 4:23 PM, Matthew Wedgwood <
matthew.wedgwood at canonical.com> wrote:

> On 08/23/2013 04:30 AM, William Reade wrote:
> > * it's *not* a problem for units that merely "provide" a
> > service to units on the other side of a relation, because (while they
> > may well want to reconfigure by revoking access for the dying unit)
> > their operation should not be materially affected by the
> > disappearance of a dying requirer unit
>
> I've come across many cases while writing charms where it's hard to work
> out which end of a relation is the provider and which one is the requirer.
> That model doesn't always fit.
>

I certainly understand it's possible to implement relations the "wrong" way
round, but I'd really like to see some examples that already exist and need
to be accommodated.


> Consider a pub-sub service where the provider is the one that initiates
> connections. Reverse proxies are similar in nature. It think it's incorrect
> to assume that it's any less urgent for the provider to know about a
> departing unit.
>

I'm not sure I understand the reverse proxy case -- the example I can think
of (haproxy) provides an external http relation, and requires the backend
http relation; so while there's a valid perspective from which it seems
that haproxy is "providing" a service to the backend services, in practice
the relation's implemented the "right" way around for our purposes (and
this is perfectly natural, because the backend is in fact "providing"
content that haproxy "requires" in ordr to do anything useful).

The pub-sub case is more interesting. It's boring but necessary for me to
state that it's clearly possible to implement them such that either (1) a
pub-sub service "requires" both publishers and subscribers or (2) some
other service (eg redis) "provides" an interface over which pub-sub can be
implemented -- and that I think both those models are quite reasonable and
natural, and fit well with the proposal -- but clearly the worrying bit is
when such a service "provides" a "subscription" relation. First of all, if
no such cases exist today, the point is moot: we can communicate that
that's not a great way to implement them, because of the (eventual)
properties of the system as proposed. But if one does exist today... I'm
still not sure that the problem is any worse than any existing case in
which a subscriber stops accepting messages for reasons unknown.

The obvious response to that is of course that the *entire proposal* is
pointless for the reasons alluded to in one of my replies to gustavo --
well written charms need to be resilient *anyway*. But I don't think that's
actually a reason not to implement the proposal: if we provide sanely
ordered relation shutdown, a charm can then reliably tell the difference
between an unexpected failure to connect (all such failures are unexpected,
because the expected cases no longer occur) and an "expected" one that's
just an artifact of unsynchronized teardown.

Pre-existing relations that are implemented the "wrong" way round are out
of luck, it's true, but I don't think the situation for them is any worse
than it already is -- a resource on which they depend is guaranteed to stop
working before they know they should stop using it.

...at least, that's my theoretical justification, and it can be trivially
punctured by finding a charm or interface that will actively break if these
changes are implemented.

Cheers
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130823/689354ba/attachment.html>