On Wed, Jun 18, 2014 at 5:04 PM, William Reade <[email protected]> wrote:
> On Tue, Jun 17, 2014 at 5:35 PM, Kapil Thangavelu < > [email protected]> wrote: >> >> 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. >> > > We're not changing any semantics; apart from anything else, > relation-broken does not depend on any remote unit. > its true it doesn't depend on one related unit, because its a change about all of them. ie. relation-broken is an event coalesce that effectively for all remote units departed and are never coming back, a relation-hook executing for a self/local unit change as opposed to remote still feels like a different semantic. > > And, in a networked world, the unit does not necessarily have a single > private address: so it's not a unit-scoped event. If we try to pretend it > is, we avoid a small amount of confusion now at the cost of much more > confusion in the imminent future. > so what happens when i have an address change on a unit that's not in a network scoped relation on that interface, the unit never gets informed of the address change? what if i have an unscoped relation that was casually using that interface? ie. not having a single private address to me is why its a unit scope change. It still feels like the issue is still we're mixing future unimplemented features with current bug fixes. > > 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. >> > > I understand this is an important bug fix. But it's not a *simple* bug > fix; it's intimately bound up with the changes imposed by the improvements > to the network model. > its a bit unclear if that's the case... could you elaborate? else how are we populating the value in the first place? and what makes it hard to update that value when we're already recording the updates/changes into state? > If everybody's just binding to 0.0.0.0 (which I accept they probably are, > and will perhaps be for a long time) it still does us, and them, no harm to > report the address they *should* bind to. And for the software that can do > better, it does no harm for them to bind to the correct addresses before > the model is fully in place. > i'd expect we'd be into nftables/iptables if we're being proactive about being more than an advisory model (also good for escaping from the sec groups scaling pain and maas secgroup parity). > > 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. >> > > The trouble is that it's tricky to track whether or not it was touched -- > especially for upgraded environments. I'd rather impose some well-flagged > breakage on the proxies -- a minority of charms -- than introduce a complex > and subtly-flaky mechanism (that will only fly for a little while) on all > charms. > > it feels like a pretty simple non-flakey solution for upgrade.. if the unit's current priv address matches the rel private-address then its the default, else its been modified by the unit and noted as such (or its just broken by iaas address change already and needs admin help to recover anyways). 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 there because I'm concerned that > relation-address-changed will otherwise become the de facto > relation-created hook -- as it is there's no place for one-time relation > setup, and people currently *have* to do it in the first relation-joined. > Giving them another option that isn't quite right will only make it harder > to figure out what's going on in a simple charm. > ic. so its a user-facing drive by feature add on the bug fix and a counterpart/parallel to relation-broken. fwiw, there were reasons why there was no relation-created in the first place (gustavo might recall better) afaicr namely that the other side might never show up and there was no unit or even service name to even associate local resources to. > > WRT unit-get: `unit-get private-address` can either grow a -r flag (with > an implicit value in relation hooks), and thus sometimes change its meaning > in existing charms; or we can introduce a new tool whose meaning is always > clear. It seems friendlier to preserve the existing behaviour of unit-get. > the unit-get private-address growing a -r flag is actually not quite right.. unit-get should always return the current iaas address not nesc. a relation bag prop. relation-get private-address JUJU_UNIT_NAME can already return this info (/me sees this in the other reply).. i'll reply there on this. > > In general, I think that *some* degree of hook-proliferation is not such a > bad thing, but I understand that it could be taken too far. > interestingly i find that most sophisticated charms have already had to give up on hook proliferation (already a given with multiple rels) and logical state transitions per rel, they simply re-render the world and reload services and use the hook simply as entry point. > The strongest argument against rel-addr-changed that I can see is that > there may be other relation-scoped changes that would fit, and that we'd > want a single hook -- as in the leader discussion, in which there seemed to > be general agreement that leader-changed could be rolled into > config-changed. In particular, then, the mooted relation-config-changed > hook would perhaps suffice. Thoughts? > assuming relation config feature existed it would be a reasonable fallback for this although forcing unit level address changes through relation scoping doesn't address how to deal with unscoped changes (ie addresses/interfaces not bound to rels). Also in the case of container addressability its unclear if this change is detectable at the unit level (ip forward on the host, the unit interface addr isn't nesc changing). -k
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
