Relation addresses

[Kapil Thangavelu]

On Wed, Jun 18, 2014 at 5:04 PM, William Reade <william.reade at canonical.com>
wrote:

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

its true it doesn't depend on one related unit, because its a change about
all of them. ie. relation-broken is an event coalesce that effectively for
all remote units departed and are never coming back,  a relation-hook
executing for a self/local unit change as opposed to remote still feels
like a different semantic.


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


so what happens when i have an address change on a unit  that's not in a
network scoped relation on that interface, the unit never gets informed of
the address change? what if i have an unscoped relation that was casually
using that interface?  ie. not having a single private address to me is why
its a unit scope change. It still feels like the issue is still we're
mixing future unimplemented features with current bug fixes.


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

its a bit unclear if that's the case... could you elaborate?   else how are
we populating the value in the first place? and what makes it hard to
update that value when we're already recording the updates/changes into
state?


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

i'd expect we'd be into nftables/iptables if we're being proactive about
being more than an advisory model (also good for escaping from the sec
groups scaling pain and maas secgroup parity).


>
> 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.
>
>
it feels like a pretty simple non-flakey solution for upgrade.. if the
unit's current priv address matches the rel private-address then its the
default, else its been modified by the unit and noted as such (or its just
broken by iaas address change already  and needs admin help to recover
anyways).

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

ic. so its a user-facing drive by feature add on the bug fix and a
counterpart/parallel to relation-broken. fwiw, there were reasons why there
was no relation-created in the first place (gustavo might recall better)
afaicr namely that the other side might never show up and there was no unit
 or even service name to even associate local resources to.


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

the unit-get private-address growing a -r flag is actually not quite
right.. unit-get should always return the current iaas address not nesc. a
relation bag prop. relation-get private-address JUJU_UNIT_NAME can already
return this info (/me sees this in the other reply).. i'll reply there on
this.


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

interestingly i find that most sophisticated charms have already had to
give up on hook proliferation (already a given with multiple rels) and
logical state transitions per rel, they simply re-render the world and
reload services and use the hook simply as entry point.


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

assuming relation config feature existed it would be a reasonable fallback
for this although forcing unit level address changes through relation
scoping doesn't address how to deal with unscoped changes (ie
addresses/interfaces not bound to rels). Also in the case of container
addressability its unclear if this change is detectable at the unit level
(ip forward  on the host, the unit interface addr isn't nesc changing).

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