Well, given it is "unit-get" shouldn't it be more "relation-get private-address" ? The issue is *that* is "give me the private-address for the other side of this relation". Which is not quite what you want. And while I think it is true that many things won't be able to handle binding to more than one ip address (its either everything with 0.0.0.0 or one thing), I think we should at least make it *possible* for well formed services to behave the way we would like.
John =:-> On Wed, Jun 18, 2014 at 6:12 AM, Andrew Wilkins < andrew.wilk...@canonical.com> wrote: > 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
