[00:48] [ANN] juju-core 1.9.3 has been released [00:48] https://lists.ubuntu.com/archives/juju-dev/2012-December/000333.html [04:56] davecheney: g'day, i have a problem you might me able to help me solve if you have a moment to take a look. [05:09] wallyworld_: shoot [05:10] davecheney: see https://codereview.appspot.com/6874049/patch/1/7, the TODO about 2/3 of the way down // TODO: WHY DOESN't THIS WORK? [05:10] you may not have an idea of what's wrong. i can't see it right now [05:10] the array ends up filled with the last id [05:11] so if there are 2 servers, the array becomes [id2, id2] instead of [id1, id1] [05:11] [id1, id2] i mean [05:11] wallyworld_: yes, this is one of two gotchas with go [05:11] only 2? [05:11] (the other is also to do with scoping of variables [05:12] (well, two that I consider gotchas) [05:12] so what am i missing? [05:13] i use append elsewhere in similar circumstances and it seems to work [05:13] if you do s := server ; insts = append( ...) [05:13] it will work [05:14] wtf? why? [05:14] hold on, i'll explain [05:14] just looking at why you're doing := range *servers [05:14] ok [05:15] the api returns a pointer to an array of structs [05:15] due to that big discussion i had on irc last week [05:15] about returning nil if the json failed [05:15] ok, i don't want to get into that [05:15] me either :-) [05:15] just providing context [05:16] as to why it is a pointer [05:16] if we break down the for loop, what is happening behind hte scenes you're getting [05:16] var server Nova.server [05:16] for i := 0 ; i < len(*servers); i++ { [05:16] server = *servers[j] [05:16] ... then your code [05:16] } [05:17] (this is part of the explanation) [05:17] *servers[i]? [05:17] do you agree that this can be subtituted for the range above [05:17] yes [05:17] with the i [05:17] yes, sorry [05:17] np, just making sure [05:17] so inside each loop iteration it becomes [05:18] server = *servers[i] (hidden) [05:18] insts = append(insts, &instance{e, &server}) [05:19] &server is capturing the address of the local server variable every time [05:19] the same local server variable [05:19] which is why they all end up as the last value assigned to it [05:20] * wallyworld_ thinks [05:21] davecheney: so by doing s:= server, it forces a copy to be made? [05:21] yes [05:22] ok, i think i get it. is the moral of the story not to use loop variables in certain circumstances? [05:22] when taking their address [05:22] sadly this is just one thing you have to be ever vigilant for [05:23] right, ok. thanks so much. i wasted a loooong time on this [05:23] sorry, it is one of the rights of passage [05:23] lol [05:24] i still don't feel like Go is "native" just yet, but it's getting there [05:24] that's good to hear [05:24] i'm constantly amazed at how quickly can pick up the language [05:24] it tells me it's doing something right [05:25] yeah, there's some stuff i don't like, but it's interesting to work with [05:25] wallyworld_: btw, do you feel that any sort of decision was reached about the 'when and how should we meet' discussion ? [05:25] in the meeting I got the impression, and looking at the notes, that the decision to not change anything was made [05:25] my understanding was alternating times 21:00UTC and 09:00UTC [05:25] then the day after Mark posted an email saying we're going to do that [05:26] alternating times ?! [05:26] i read that as two meetings [05:26] it was explained to me as alternating and you would make whichever meeting you could [05:26] or both [05:26] but, alternating every other week ? [05:26] yes [05:27] unless i am mistaken [05:27] so we can go an entire milestone cycle without meeting or feedback ? [05:27] is each milestone cycle 2 weeks? [05:27] i think for you and me we can make both [05:27] you can see we run a pretty loose ship on juju-core, but yes, ish [05:28] to be honest, the current one that is 10pm for me i can make most weeks [05:28] it's 11pm for me [05:28] yeah, DST :-) [05:28] and i'm getting pressure from home [05:28] which i guess is why they changed it [05:29] timezones suck sometimes [05:29] happy wife, happy life [05:29] i'm not sure if tomorrow's meeting is still at 0pm, will have to check [05:33] DST is bitch if you need to coordinate with western europe [05:33] 7pm UK time is 6am AEST [05:33] (or is that AEDT [05:34] i thought it was 7am AEST [05:35] nup [05:35] http://everytimezone.com/ [05:35] not 7pm, 9pm [05:35] 21:00UTC [05:35] so +10 is 7am for me [06:50] Morning [06:51] morning [06:51] davecheney: Had a nice weekend? === TheMue_ is now known as TheMue [08:34] morning all === rogpeppe2 is now known as rogpeppe [08:40] Hiya rogpeppe [08:45] rogpeppe, TheMue, heyhey [08:45] rogpeppe, TheMue: I would appreciate your opinions on the Living interface [08:45] fwereade: Hi [08:46] fwereade: just jotting down some thoughts i had over the weekend. will have a look in a bit, thanks for the heads up. [08:46] rogpeppe, TheMue: it only seems to be used for the tests [08:46] rogpeppe, TheMue: and I have slight concern that it doesn't really fit our needs [08:46] fwereade: what CL are we talking about? [08:47] rogpeppe, it's a piece that's already in place [08:47] fwereade: ah [08:47] rogpeppe, state/life.go [08:47] rogpeppe, it has EnsureDying/EnsureDead [08:47] fwereade: you're objecting to those methods? [08:47] rogpeppe, we took those methods off Relation because they didn't make sense [08:48] fwereade: If you say you have concerns that it fits our needs, then please start by definig what you think our needs are. [08:48] rogpeppe, and while they're ok for unit they don't express enough [08:48] fwereade: do you think Unit needs a richer interface than a simple "EnsureDead"? [08:49] fwereade: or EnsureDying [08:49] rogpeppe, yeah -- remove-unit --force [08:49] rogpeppe, we need a way to say, politely, "please kill yourself"; a way to say politely "I'm done, clean me up"; and a way to force dead immediately [08:50] fwereade: ah, so EnsureDying isn't allowed to take account of things that might block the EnsureDying [08:50] rogpeppe, yeah, nothing should block an EnsureDying [08:50] fwereade: emr [08:50] rogpeppe, depending on the circumstances, the existence of subordinates may or may not want to block EnsureDead [08:50] erm [08:51] fwereade: istm that EnsureDying *is* a way to say, politely, "please kill yourself" [08:51] fwereade: and that EnsureDead *is* a way to force dead immediately [08:51] rogpeppe: That's how I understood it too. [08:51] rogpeppe, yes... we have 3 things to express, and 2 0-arg methods [08:52] fwereade: that doesn't sound like the current interface is wrong, but that some things may need more [08:53] rogpeppe, maybe [08:53] fwereade: Please match the current methods to your three sentences above to make sure which one you don't see covered. [08:53] rogpeppe, bear in mind that it was already dropped from relation because it's useless [08:54] fwereade: how do you remove a relation then? [08:54] rogpeppe, TheMue: EnsureDying=please kill yourself, EnsureDead=die immediately; no way to politely signal your own death [08:54] rogpeppe, it depends [08:54] rogpeppe, I ca dredge up the details if you like [08:55] fwereade: by "signal your own death", do you mean there's no way to tell others when you've died? [08:55] rogpeppe, there is no convenient way for me to coordinate the unit's death amongst various tasks [08:55] fwereade: So you want a kind of destructor. But that is something the entitiy has to signal. It isn't signalled from the outside to the entitiy. [08:55] fwereade: i'm not sure what you mean by that [08:57] rogpeppe, ok, maybe I should shift perspective around and see what sorts of statements we agree on [08:57] rogpeppe, the only thing that can sanely set a machine to Dead is a machine agent; agreed? [08:57] rogpeppe, and the only thing that can sanely set it to Dying is the user [08:58] fwereade: How would you name that third method? And who will call it? [08:58] fwereade: i'm not sure. what if the machine has gone away and isn't coming back? [08:58] rogpeppe, do you mean the "instance" [08:58] fwereade: yeah [08:58] rogpeppe, I don't think that's relevant then? [08:58] rogpeppe, juju will provision a new one and put the machine agent on it [08:59] fwereade: do we have to resurrect the instance and its machine agent in order to kill the Machine? [09:00] * TheMue still thinks it's a wrong perspective. The first two methods are telling the entity that it has something to to, the missing one is used by the entity itself to signal the outer world that a state is reached and the outer world has something to do. [09:00] s/to to/to do/ [09:00] rogpeppe, you're talking like we can *stop* juju from provisioning a new instance for a broken machine? [09:01] TheMue, ok [09:01] TheMue, what does service.EnsureDead do? [09:02] TheMue, btw you are wrong re methods: if an entity is dead, it must *not* do anything, and in the normal case of affairs it doesn't even see itself become dead because it sets and terminates itself [09:02] fwereade: It sets the entity to dead. [09:03] TheMue, the notion of EnsureDead from outside the entity is only sane in the case of units, and that's only because we carved out an exception for remove-unit--force [09:03] TheMue, ok, and what happens when you do that? [09:04] TheMue, and more to the point, when is it ok to do that? [09:04] fwereade: what if an instance goes down and the user calls terminate-machine before it's been reprovisioned? [09:05] fwereade: I would have to take a look what's done today. But IMHO after an entity is marked as dead it can be cleaned up. [09:05] rogpeppe, if we can detect that for sure, then we can remove it; no reason to make it dead [09:05] TheMue, think through what will happen if we set a service to Dead [09:05] TheMue, what should happen to the units of that service? [09:05] fwereade: I'm currently looking from a more abstracte perspective about where methods have to apply. [09:05] fwereade: doesn't it have to be dead before we remove it? [09:06] rogpeppe, not at all, we don't do that with relations [09:06] fwereade: IMHO they should be set to dead too, before the service is marked as dead. [09:06] rogpeppe, I'm not sure the Dead state is even meaningful for relations or services [09:06] TheMue, how will you craft your request to set 100k units to Dead? [09:08] fwereade: I have no quick answer. But logically, if a service shall be set to dead, shouldn't the units be dead too? [09:08] TheMue, using the txn package, remember [09:08] TheMue, logically, yes [09:08] TheMue, but there are 2 possibilities here [09:08] TheMue, we can set services to dead, and get crack, or wee can admit that service.EnsureDead is (probably) crack [09:08] fwereade: anyway, sorry that was a derail. say, for the sake of argument, we accept that only a machine agent can set its machine to dead. what then? [09:09] fwereade: are you saying that if we set something to dead, we may as well just remove it? [09:09] rogpeppe, ok, so machines are easy: Dying from outside, Dead from inside [09:09] rogpeppe: Do we mix topics here? [09:10] rogpeppe, not at all -- I'm saying that relations and services have no use for a Dead state, because we can just remove when appropriate [09:10] rogpeppe, units and machines *do* have a use for the dead state [09:11] * TheMue would like to stay on the path what should happen to units, independent of their number, when their service is said that it shall die. [09:11] rogpeppe, but the agreement thus far has been that the only one we should be setting to dead from outside was unit, and that in a not-especially-high-priority feature [09:11] TheMue, what we do is set the service to Dying [09:11] TheMue, every unit is the responsible for setting itself to dying and cleaning itself up [09:12] TheMue, the units' deployer waits for it to become dead [09:12] fwereade: Is every unit watching it's services' lifecycle? [09:12] TheMue, yes [09:12] fwereade: Ah, ok, missed that, thanks. [09:13] fwereade: it sounds like you're arguing for removing EnsureDead [09:13] sorry 1 sec [09:13] rogpeppe, I'm not stronly arguing *for* anything, I'm just trying to raise the topic for discussion in the hope something will be synthesized therefrom [09:13] TheMue, to continue: then the deployer removes the unit [09:14] fwereade: And markes it as dead? [09:14] TheMue, the unit marked itself as dead [09:14] TheMue, the deployer is then responsible for uninstalling it and removing it from state [09:14] fwereade: How does it mark itself as dead? [09:14] TheMue, and removing its service from state if it was the last member of a dying unit [09:15] TheMue, at the moment it calls EnsureDead [09:15] fwereade: The unit calls EnsureDead() on itself? Aha. [09:15] TheMue, but this will not work correctly in the presence of subordinates [09:15] TheMue, yes [09:15] TheMue, in general only an entity is meant to declare itself dead [09:16] fwereade: Could you give me a hint where in the code this happens? [09:16] TheMue, the EnsureDead? worker/uniter/modes.go [09:16] TheMue, ModeStop or something? ModeDie? [09:16] fwereade: So the uniter calls it, not the unit. [09:16] TheMue, what part of the unit has its own volition if not the uniter? [09:16] back in a mo [09:17] fwereade: It's only the wording I want to get sure. If I talk about Unit it's state.Unit. Not about the uniter. [09:18] TheMue, sure, sorry, I didn't mean to be unclear [09:18] fwereade: I only wanted to clear that to not be confused. [09:18] fwereade: I never been deep in the uniter. So that's important to me to get a similar context. [09:18] TheMue, I think of a Unit as a dumb type manipulated by interesting clients -- the clients are the agents and the command line [09:19] back [09:19] fwereade: OK, now it's more clear, thanks. [09:20] rogpeppe, actually, how do you expect we will set a machine to dead? thinking about it, that sounds like a job for the machiner [09:20] rogpeppe, and it sounds like exactly the same problem as the uniter has [09:20] fwereade: is the provisioner right to allocate a new instance for a machine that's set to dying? [09:21] rogpeppe, if it's still meant to be running a unit, yes, unless you have a better idea [09:21] rogpeppe, but I forget: did we agree that we couldn't set a machine to dying until it had no assigned units? [09:22] fwereade: i thought we could always set something to *dying* [09:22] rogpeppe, I haven't thought so much about machine lifecycles, which is probably why I perceive them as a simple problem.. I bet they aren't really ;p [09:23] fwereade: i have a suspicion we have some muddy thinking about the machine/instance/unit relationship [09:23] rogpeppe, ok, so terminate-machine shouldn't actually terminate the machine? [09:24] rogpeppe, ok, please explain your view of the situation [09:24] rogpeppe, is it your position that terminate-machine should also terminate all the units on that machine? [09:24] fwereade: i don't have a strong notion of *how* our thinking is muddy, just that i don't clearly understand things, and i'm not sure anyone else does [09:24] rogpeppe, beacuse it has hitherto meant "I will never use this unused machine again", and been blocked by the machine's having units deployed [09:25] fwereade: ok, well that sounds reasonable [09:25] rogpeppe, ok, you know what? this makes me question EnsureDying/EnsureDead still more [09:26] fwereade: so... say a machine is unused but its instance has just died; someone calls terminate-machine before the provisioner has noticed that the instance is dead. [09:26] fwereade: when the provisioner notices that the instance is dead, should it allocate another one? [09:27] fwereade: i don't see any question about EnsureDying [09:28] fwereade: EnsureDead seems to be the problematic part of the interface [09:29] rogpeppe, ok, what does it do? [09:29] rogpeppe, please describe the chain of consequences from EnsureDying [09:30] fwereade: the provisioner can see when an instance dies, right? [09:31] rogpeppe, yeah, I think so, roughly [09:31] fwereade: (i'm not actually sure that it can, tbh, but this we seem to believe it) [09:31] s/this we/we/ [09:31] rogpeppe, I think it s possible to infer it anyway [09:31] fwereade: i'm not sure it is [09:31] fwereade: in the presence of network failures [09:32] fwereade: anyway, assuming we can [09:32] fwereade: when the provisioner sees an instance go down, it allocates a new one and assigns the old Machine to it, right? [09:32] rogpeppe, yeah [09:33] fwereade: so if someone has called EnsureDying on that machine, should the provisioner really allocate a new instance for the machine? [09:33] fwereade: (surely not?!) [09:34] rogpeppe, if a machine is Dying it means "I will set myself to Dead when I have disacharged my responsibilities" [09:34] fwereade: what is a machine without an instance? [09:35] rogpeppe, I am reluctant to stipulate that the machine agent can die with no responsibilities undischarged [09:35] fwereade: what responsibilities does a machine agent have if it has no units? [09:36] rogpeppe, I suspect storage handling will come into play mostly at the machine agent level [09:37] rogpeppe, but, ok -- that's a potential derail [09:37] fwereade: i just think it's weird that we'd allocate a new instance only to shut it down immediately [09:37] rogpeppe, what you say makes sense, but you're not taking it far enough [09:37] fwereade: i think the provisioner can proxy for the machine agent in this instance [09:38] rogpeppe, what does Dying actually mean if the unit agent can only go to Dying when it has no responsibilities left to discharge? [09:38] rogpeppe, it means Dying is not a sane state for a Machine to have [09:39] rogpeppe, it will become so if/when we change the rules ofc... [09:39] fwereade: sorry, you're mixing up machine dying and unit dying in a way i don't quite understand [09:40] rogpeppe, shit sorry s/unit/machine/ [09:40] s/unit agent/machine/ actually [09:40] fwereade: it sounds reasonably sane to me [09:41] rogpeppe, what is the distinction between Dying and Dead for a machine? [09:42] fwereade: i think it's a pity we haven't actually implemented terminate-machine yet... [09:43] rogpeppe, although, sorry, I'm derailing a little and I have no particular interest in fighting this one -- I take a similar Dying shortcut in the Deployer, actually [09:43] rogpeppe, but I'm actually questioning it [09:44] fwereade: because you're saying that a machine can only go to Dying when it has no responsibilities left to discharge, but that's not the case currently [09:44] fwereade: anyone can set a machine to dying at any time [09:44] rogpeppe, ok, well then that is surely crack [09:44] rogpeppe, why timebomb your machines like that? [09:44] fwereade: i'm not sure why [09:45] fwereade: you might have a good reason [09:45] fwereade: you might not want a new machine to be allocated [09:45] rogpeppe, the only thing that does is to say "keep this machine around for an arbitrary length of time, but don't forget the irrevocable kill command that will take effect when its current purpose is fulfilled" [09:45] fwereade: so calling terminate-machine before removing a unit means that we can ensure that's true [09:46] fwereade: that seems quite plausibly useful to me [09:46] rogpeppe, but you're also suggesting that the unit should get no opportunity to shut down cleanly if the instance goes away [09:46] rogpeppe, it's a total niche case [09:46] rogpeppe, defaulting to shutting down machines when unused would be moreuseful [09:46] rogpeppe, weeks-delayed kill commands are pretty esoteric ;) [09:47] fwereade: if we think that automatically shutting down a machine when it's unused is a good thing, then sure. but i think we've decided that it's not. [09:47] rogpeppe, I am working on the asusmption that we will have some sort of persistent storage generally available, such that moving from one instance to another can be accomplished almost trivially [09:48] rogpeppe, my point is that if we're going to get clever about machine termination, delayed-kill is not the top priority [09:48] fwereade: well maybe, but there is overhead in starting an instance, and state in an instance that may not be easily stored. [09:48] fwereade: i think it falls out naturally from our model. [09:48] rogpeppe, yeah, depends on the provider [09:49] fwereade: and it *is* potentially useful behaviour [09:49] rogpeppe, it is potentially useful behaviour that we should restrain ourselves from implementing until we understand the use cases [09:51] rogpeppe, you know what [09:52] rogpeppe, Unit.EnsureDead, implemented correctly, is just *horribly* complex [09:53] fwereade: because it's hard to check all the unit's dependencies before setting state to dead? [09:53] rogpeppe, it needs to clean up some or all of: machine assignment, subordinates Dead-setting, relation removal, and service removal [09:53] rogpeppe, if we do it correctly, we have to just build up some monster transaction [09:54] rogpeppe, not to mention just cleaning up relation membership [09:54] fwereade: that's not Unit.EnsureDead - that's RemoveUnit [09:54] fwereade: EnsureDead and EnsureDying don't do anything other than set life state [09:54] rogpeppe, ok, drop service removal [09:54] rogpeppe, that's the only one [09:55] fwereade: it's up to the caller to make sure that the other invariants are preserved correctly. [09:55] rogpeppe, ha ha [09:55] rogpeppe, how is that possible? [09:56] fwereade: well usually we do that be not allowing new things to be added when something is in a dying state. [09:56] rogpeppe, to make sane transitions in system state we have to do these things as single transactions [09:56] good morning [09:56] Aram: hiya! [09:56] Aram, heyhey [09:56] Aram, nice holiday? [09:56] yeah. [09:56] Aram, cool [09:57] Aram: is your holiday finished now? [09:57] yeah. [09:57] Aram, I landed your watchers -- we've identified the firewaller bug and TheMue is looking into it this week AIUI [09:57] fwereade, Aram: +1 [09:57] fwereade, could you please link me to the commit that fixed it? [09:57] Aram: Hello btw. [09:57] hi. [09:58] fwereade: i'm not sure we do need to do these things as single transactions [09:58] fwereade: and that's why we have the dying/dead distinction [09:58] rogpeppe, Dying/Dead is about handover of responsibility surely [09:58] Aram: It's not yet fixed, only better identified. I'm now working on it with two CLs. [09:59] rogpeppe, but any time we want to make a change to the state, we need to do it as a single transation [09:59] rogpeppe, or write a CA [09:59] fwereade: CA? [09:59] rogpeppe, Corrective Agent ;) [09:59] fwereade: ha [09:59] Aram: And LXC is right now stopped, one CL has gone in, two are open. MAAS has gotten higher priority. [09:59] fwereade: but that's not true. we don't need to make every change to the state as a single transaction [09:59] fwereade, I've seen a proposal to replace int with string, excellent. [10:00] Aram, (there was a MUW bug that was contributing to that test failing, I'll find that commit, just a mo) [10:00] fwereade: and in this case, after the unit is set to dying, if we use several transactions to find that all its dependencies have gone away and it's in dying state, then we know we can remove it [10:00] fwereade: or set it to dead [10:01] meh, the damn unity panel can't be set in a different position, and auto hide doesn't work in vmware. [10:03] Aram: so run ubuntu natively :-) [10:07] I bought a new mac. [10:08] Aram: It's possible to auto-hide it, have to find the switch again. Somwhere in the settings. [10:09] TheMue, it's possible to auto hide it, it's impossible to appear again after you've done so. [10:09] that's because compiz is too smart for its own good. [10:09] *lol [10:09] it calculates how hard you've hit the screen edge. [10:10] since vmware won't deliver mouse events after you've hit the edge, it can't calculate how hard you hit it. [10:10] so it won't show up. === Aram2 is now known as Aram [11:00] so, hey again all [11:01] fwereade: your network connection die? [11:01] rogpeppe, power cut [11:01] fwereade: ah, not useful [11:02] rogpeppe, didn't last long :0 [11:05] rogpeppe, ok, so, the trouble with lifecycle discussions is that there are in the end fewer commonalities than one might think [11:05] fwereade: did you see my last commend ("... or set it to dead")? [11:05] comment [11:05] rogpeppe, ah, sorry, I didn't [11:05] fwereade: ah [11:05] [09:59:49] fwereade: but that's not true. we don't need to make every change to the state as a single transaction [11:05] [10:00:36] fwereade: and in this case, after the unit is set to dying, if we use several transactions to find that all its dependencies have gone away and it's in dying state, then we know we can remove it [11:06] [10:00:42] fwereade: or set it to dead [11:06] rogpeppe, ok, so what's the scenario you're considering there? [11:07] fwereade: i was replying to your "but any time we want to make a change to the state, we need to do it as a single transation" comment [11:07] rogpeppe, yeah, and you're explaining a situation in which we don't have to worry about it, and I'm asking for more details [11:07] rogpeppe, I think :) [11:07] rogpeppe, who is setting the unit to dying, and why? [11:08] fwereade: i was talking about setting the unit to dead, not dying [11:08] fwereade: anyone can set the unit to dying [11:08] network here is a bit flakey, but I'm around again for the next few hours today, and then traveling back to the US tomorrow. [11:08] mramm: i guess you'll miss the meeting then [11:08] dimitern: want to catch up, even though it'll only be us two? [11:08] rogpeppe: yea [11:09] rogpeppe: I also need to figure out better meeting times [11:09] rogpeppe, ok, yes, that is true; it is not hard to set a unit to dead once we know it's done everything [11:09] rogpeppe, but the tricky case is EnsureDead from the outside [11:10] fwereade: i don't see that's a problem. the only thing that can call EnsureDead is something that knows it can act for the object. [11:10] fwereade: which is usually the agent responsible for the object, but may not be, in some cases. [11:11] rogpeppe, ok, so when someone uses remove-unit --force... [11:11] rogpeppe, that client is basically taking on all the responsibilities of the unit agent, right? [11:11] fwereade: i'm not sure [11:12] rogpeppe, well, the UA won't do anything else after it's dead [11:12] fwereade: i don't think the client can call EnsureDead in that case [11:12] mgz: sure, i'm starting mumble now [11:12] rogpeppe, its responsibilities must either be transferred elsewhere, or discharged, in the same transaction that makes it Dead [11:12] fwereade: i think it just means "unit: please remove yourself regardless of the dependencies" [11:13] rogpeppe, I don't think there's any command that means "please corrupt state" [11:13] fwereade: i don't see why it all needs to happen in the same transaction [11:13] rogpeppe, ok, so what happens when the first change is made and then the connection is dropped? [11:14] fwereade: all we need to do is set the unit to dying and some flag, say "force" that means that the unit will kill itself even when it has relations etc. [11:14] s/"force"/"force",/ [11:15] rogpeppe, please expand on what you mean by "kill itself" [11:15] rogpeppe, it needs to exit the relations even if it isn't running hooks [11:15] fwereade: well, perhaps it might be good if you could explain the sematics of remove-unit --force. [11:16] rogpeppe, the idea was from possibly the first lisbon [11:16] semantics [11:17] rogpeppe, make the unit Dead [11:17] rogpeppe, the trouble is that "make the unit Dead" is not necessarily a simple change to state [11:17] fwereade: at a higher level, why do we want this? [11:17] rogpeppe, because a broken UA is a hugely awful failure, that otherwise blocks the removal of machines, services, and relations [11:18] rogpeppe, it's a feature we hope nobody will use [11:18] fwereade: ok. are we talking about a broken unit agent, or a dead instance? [11:18] rogpeppe, a broken unit agent [11:18] rogpeppe, that has bad code, and bad upgrading code too, and that we have no other way of removing [11:19] fwereade: so if we know it's broken, then we know we can act for it, right? [11:19] rogpeppe, sure, I'm 100% comfortable with the idea that we can tak on its responsibilities [11:20]