On Fri, Aug 23, 2013 at 4:23 PM, Matthew Wedgwood < [email protected]> 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
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
