Relation addresses

[Andrew Wilkins]

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/a6f40321/attachment.html>