On Wed, Jun 18, 2014 at 2:56 PM, Andrew Wilkins < [email protected]> wrote:
> On Tue, Jun 17, 2014 at 9:29 PM, John Meinel <[email protected]> > 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.
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
