Relation addresses

[John Meinel]

It probably wouldn't be a terrible approximation to compare the current
value of the machine's private address to the value currently listed as the
private-address. We'd want to be clear about it in our upgrade notes that
if your machine changed address since it was deployed (before it was
upgraded) then things may not work correctly. But I think it would have
already been broken, so probably not a big deal. (If the current private
address isn't the actual machine address and it is supposed to be, then
we're already in a broken state.)
The only race is if *while upgrading* the machine address changes. But
there again, because we didn't update private-address anyway, it would have
been broken by that action.

On balance, I still prefer the design we went with, but this is one of
those places where there are multiple ways to handle it, and the choice is
a balance of tradeoffs.

Yes we break existing proxy charms, but we unbreak all the charms that
aren't proxies, and we would be able to do it without having to double
record data (only putting it somewhere safe, making sure we don't trigger
watches when we update it, etc).

John
=:->


On Wed, Jun 18, 2014 at 11:01 AM, Andrew Wilkins <
andrew.wilkins at canonical.com> wrote:

> On Wed, Jun 18, 2014 at 2:56 PM, Andrew Wilkins <
> andrew.wilkins at canonical.com> wrote:
>
>> On Tue, Jun 17, 2014 at 9:29 PM, John Meinel <john at arbash-meinel.com>
>> wrote:
>>
>>> ...
>>>
>>>
>>>>  In a nutshell:
>>>>>  - There will be a new hook, relation-address-changed, and a new tool
>>>>> called address-get.
>>>>>
>>>>
>>>> This seems less than ideal, we already have standards ways of getting
>>>> this data and being notified of its change. introducing non-orthogonal ways
>>>> of doing the same lacks value afaics or at least any rationale in the
>>>> document.
>>>>
>>>
>>> So maybe the spec isn't very clear, but the idea is that the new hook is
>>> called on the unit when *its* private address might have changed, to give
>>> it a chance to respond. After which, "relation-changed" is called on all
>>> the associated units to let them know that the address they need to connect
>>> to has changed.
>>>
>>> It would be possible to just roll relation-address-changed into config
>>> changed.
>>>
>>> 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.
>>>
>>>
>>>
>>>> the two perspectives of addresses for self vs related also seem to be a
>>>> bit muddled. a relation hook is called in notification of a remote unit
>>>> change, but now we're introducing one that behaves in the opposite manner
>>>> of every other, and we're calling it redundantly for every relation instead
>>>> of once for the unit?
>>>>
>>>>
>>>>>  - The hook will be called when the relation's address has changed,
>>>>> and the tool can be called to obtain the address. If the hook is not
>>>>> implemented, the private-address setting will be updated. Otherwise it is
>>>>> down to you to decide how you want to react to address changs (e.g. for
>>>>> proxy charms, probably just don't do anything.)
>>>>>
>>>>
>>>> perhaps there is a  misunderstanding of proxies, but things that set
>>>> their own address have taken responsibility for it. ie juju only updates
>>>> private address if it provided it, else its the charms responsibility.
>>>>
>>>> fwiw, i think this could use some additional discussion.
>>>>
>>>>
>>> So one of the reasons is that it takes some double handling of values to
>>> know if the existing value was the one that was what we last set it. And
>>> there is the possibility that it has changed 2 times, and it was the value
>>> we set it to, but that was the address before this one and we just haven't
>>> gotten to update it.
>>> There was a proposal that we could effectively have 2 fields "this is
>>> the private address you are sharing, which might be empty" and "this is the
>>> private address we set" which is where we put our data. And we return the
>>> second value if the first is still nil. Or we set it twice, and we only set
>>> the first one if it matches what was in the second one, etc.
>>> All these things are possible, but in the discussions we had it seemed
>>> simpler to not have to track extra data for marginal benefit. Things which
>>> are proxy charms know that they are, and they found the right address to
>>> give in the past, and they simply do the same thing again when told that we
>>> want to change their address.
>>>
>>
>> There are certainly options for new units, but how about existing units
>> after an upgrade? The only thing I can think of that'd work is to trawl
>> txns.log for the initial transaction that created the relation settings
>> doc, and use that as the original value. We could do that as an upgrade
>> step (trawl log, store original value in relation settings with a special
>> key). I expect it'd potentially be quite slow.
>>
>
> Actually, even that's not guaranteed to work because the transaction log
> is capped.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140618/932bea29/attachment.html>