Relation addresses

[William Reade]

On Tue, Jun 17, 2014 at 5:35 PM, Kapil Thangavelu <
kapil.thangavelu at canonical.com> wrote:
>
> or another unit level change hook (unit-address-changed), again the
> concerns are that we're changing the semantics of relation hooks to
> something fundamentally different for this one case (every other relation
> hook is called for a remote unit) and that we're doing potentially
> redundant event expansion and hook queuing as opposed to
> coalescing/executing the address set change directly at the unit scope
> level.
>

We're not changing any semantics; apart from anything else, relation-broken
does not depend on any remote unit.

And, in a networked world, the unit does not necessarily have a single
private address: so it's not a unit-scoped event. If we try to pretend it
is, we avoid a small amount of confusion now at the cost of much more
confusion in the imminent future.

The reason it is called for each associated unit is because the network
>> model means we can actually have different addresses (be connected on a
>> different network) for different things related to me.
>>
>> e.g. I have a postgres charm related to application on network A, but
>> related to my-statistics-aggregator on network B. The address it needs to
>> give to "application" should be different than the address given to
>> "my-statistics-aggregator". And, I believe, the config in pg_hba.conf would
>> actually be different.
>>
>>
> thanks, that scenario would be useful to have in the spec doc. As long as
> we're talking about unimplemented features guiding current bug fixes,
> realistically there's quite a lot of software that only knows how to listen
> on one address, so for network scoped relations to be more than advisory
> would also need juju to perform some form of nftables/iptables mgmt. Its
> feels a bit slippery that we'd be exposing the user to new concepts and
> features that are half-finished and not backwards-compatible for proxy
> charms as part of a imo critical bug fix.
>

I understand this is an important bug fix. But it's not a *simple* bug fix;
it's intimately bound up with the changes imposed by the improvements to
the network model. If everybody's just binding to 0.0.0.0 (which I accept
they probably are, and will perhaps be for a long time) it still does us,
and them, no harm to report the address they *should* bind to. And for the
software that can do better, it does no harm for them to bind to the
correct addresses before the model is fully in place.

there's lots of other implementation complexity in juju that we don't leak,
> we just try to present a simple interface to it. we'd be breaking existing
> proxy charms if we update the values out from the changed values. The
> simple basis of update being you touched you own it and if you didn't it
> updates, is simple, explicit, and backwards compatible imo.
>

The trouble is that it's tricky to track whether or not it was touched --
especially for upgraded environments. I'd rather impose some well-flagged
breakage on the proxies -- a minority of charms -- than introduce a complex
and subtly-flaky mechanism (that will only fly for a little while) on all
charms.

There's also the question of why the other new hook (relation-created) is
> needed or how it relates to this functionality, or why the existing
> unit-get private-address needs to be supplemented by address-get.
>

relation-created is there because I'm concerned that
relation-address-changed will otherwise become the de facto
relation-created hook -- as it is there's no place for one-time relation
setup, and people currently *have* to do it in the first relation-joined.
Giving them another option that isn't quite right will only make it harder
to figure out what's going on in a simple charm.

WRT unit-get: `unit-get private-address` can either grow a -r flag (with an
implicit value in relation hooks), and thus sometimes change its meaning in
existing charms; or we can introduce a new tool whose meaning is always
clear. It seems friendlier to preserve the existing behaviour of unit-get.

In general, I think that *some* degree of hook-proliferation is not such a
bad thing, but I understand that it could be taken too far. The strongest
argument against rel-addr-changed that I can see is that there may be other
relation-scoped changes that would fit, and that we'd want a single hook --
as in the leader discussion, in which there seemed to be general agreement
that leader-changed could be rolled into config-changed. In particular,
then, the mooted relation-config-changed hook would perhaps suffice.
Thoughts?

Cheers
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140618/59cc2eaa/attachment-0001.html>