On Tue, Jun 17, 2014 at 11:35 PM, Kapil Thangavelu < kapil.thangav...@canonical.com> wrote:
> > > > On Tue, Jun 17, 2014 at 9:29 AM, John Meinel <j...@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. >> > > 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. > >> >> 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. > >> >>> 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'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. > > 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 not strictly required for this work, it just came up during discussions as a way for charms to do once-off setup of relation settings. I probably should have left it out of the doc. I suppose "unit-get private-address" could be extended to take a relation ID. > > chers, > > Kapil > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
