On Thu, Jun 19, 2014 at 12:16 AM, Kapil Thangavelu < kapil.thangav...@canonical.com> wrote: > > On Wed, Jun 18, 2014 at 5:04 PM, William Reade < > william.re...@canonical.com> wrote: >> >> 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. >
Used to be; hasn't been for a couple of years now. I'm not sure it'd be a bad thing to reinstate the pyjuju behaviour, but I think that's orthogonal regardless. 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. > Not sure I follow: every relation is implicitly scoped to the network its private-address is on anyway. There's only the one private network today, so it's not immediately obvious, but it's still true. If you're not in a relation, yes, you won't get informed by a relation-address-changed. But with the data-bag write alone, the unit never gets informed anyway. If it's lucky it runs some unrelated hook and thinks to check, but that's pretty weak: our model is that we *tell* units about the changes they need to respond to. For a sane long-term solution, this needs to be tied to a hook. I'm potentially open to arguments that address changes on interfaces not used by relations should also generate notifications... but (1) that's still a hook, even if it's a pre-existing one and (2) my gut says that a charm using such interfaces is playing silly games anyway, and I'm not sure we should go out of our way to accommodate it. And: yes, I'd love to find a clean fix that doesn't hamper future plans, but I'm not sure that's what we're getting. > 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? > OK: the state server discovers that a machine's address has changed. We can find all units on that machine, and all their relation data bags; we can find the old private-address values that match, and we can overwrite them. That's simple in isolation -- and in fact it actually stays simple in the networked relation case, because it just means we have fewer bags we need to check/update. So I was wrong there, it's not specifically about the networks; and that's good. But. The trouble comes when we have to integrate it with what the unit agent's doing: we can't assume that the unit isn't running a hook, and if it *is* then when that hook completes it's going to overwrite its data bag, quite likely blowing away the changes made on the state server. The only way I can see to work around this reliably is to eliminate the race by making the unit agent responsible for the update in the first place. (I accept that if the units don't overwrite unchanged values we'll *usually* be ok. But once we open the door to concurrent relation settings writes I think that "usually" isn't good enough.) And if we do that we *still* have issues: the unit agent needs to persistently record what it last thought its address was, so that when it comes up after reboot and sees a new address it knows it has a new one, and knows what the old one was so it can only overwrite the correct ones; and if the address changes while it's running it needs to be notified by the state server, which means a watcher; and before you know it we've built all the infrastructure we'd need to just implement the hooks in the first place. 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). > If I could think of a way to do this without introducing subtle races, I'd be convinced. A magic fix that's usually better and never worse is fine. > 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. > I'm pretty sure that the relation id is the only thing we should be associating relation-level local resources with. IMO the potential drawbacks are outweighed by the potential benefits: for every pathological case where a unit performs costly setup for a relation that never sees a remote unit, I think there will be a hundred where the ability to prepopulate the data bag for immediate use by remote units allows the whole system to converge faster with less churn and fewer total hook executions. 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. > The iaas address the unit cares about depends on the relation in play, because the network it talks on also depends on that relation. The whole notion of `unit-get private-address` *either* depends on the single-private-network model that we know won't fly, *or* it needs to grow an awareness of relations (which I'm ambivalent about, given that it's a behaviour change), *or* we want something like address-get that doesn't come with preexisting baggage. 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. > Well, yeah. I've noticed this too; and I agree that further proliferation of hooks just makes this situation suck worse. But... it sucks really badly already. You need to burn through 30 ineffectual hook executions before you can do anything, and then in the *next* 30 hook executions you just rerender config from the ground up, and bounce the service, over and over again, with changes that are probably minimal. If we want to address this, which I think we do, the answer is <smirk> another hook: the "something-changed" hook, which we only run once the hook queues are empty (or, eh, every 5 minutes if the queues still haven't emptied out). And *that* gives us a way around the hook proliferation issues: for charms of sufficient complexity, you only implement that single hook and avoid the unbridled ick of having N hooks which all call the same something-changed entry point. But that's another derail, and it's not an argument against the hook model in all cases. In the cases where that model *does* still apply, we *do* want some degree of proliferation, because hook implementation gets nastier and nastier as the set of changes that could trigger a given hook grows. In short: when your charm *can* work nicely with logical state transitions, those transitions should be relatively fine-grained, so you can actually write them as logical state transitions without drowning in conditionals; and when it can't, we're already too fine-grained, and we need to either suck it up or cut the gordian knot. 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). > public-address changes, which STM to be the only ones that aren't relation scoped, are a different matter, and even nastier. AFAICT we're going to have to end up treating expose as a one-way relation on a public network... but I'm still racking my brains on this, because I'm suspicious that I'm just reaching for a familiar hammer. Cheers William
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
