| davecheney | [ANN] juju-core 1.9.3 has been released | 00:48 |
|---|---|---|
| davecheney | https://lists.ubuntu.com/archives/juju-dev/2012-December/000333.html | 00:48 |
| wallyworld_ | davecheney: g'day, i have a problem you might me able to help me solve if you have a moment to take a look. | 04:56 |
| davecheney | wallyworld_: shoot | 05:09 |
| wallyworld_ | 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 |
| wallyworld_ | you may not have an idea of what's wrong. i can't see it right now | 05:10 |
| wallyworld_ | the array ends up filled with the last id | 05:10 |
| wallyworld_ | so if there are 2 servers, the array becomes [id2, id2] instead of [id1, id1] | 05:11 |
| wallyworld_ | [id1, id2] i mean | 05:11 |
| davecheney | wallyworld_: yes, this is one of two gotchas with go | 05:11 |
| wallyworld_ | only 2? | 05:11 |
| davecheney | (the other is also to do with scoping of variables | 05:11 |
| davecheney | (well, two that I consider gotchas) | 05:12 |
| wallyworld_ | so what am i missing? | 05:12 |
| wallyworld_ | i use append elsewhere in similar circumstances and it seems to work | 05:13 |
| davecheney | if you do s := server ; insts = append( ...) | 05:13 |
| davecheney | it will work | 05:13 |
| wallyworld_ | wtf? why? | 05:14 |
| davecheney | hold on, i'll explain | 05:14 |
| davecheney | just looking at why you're doing := range *servers | 05:14 |
| wallyworld_ | ok | 05:14 |
| wallyworld_ | the api returns a pointer to an array of structs | 05:15 |
| wallyworld_ | due to that big discussion i had on irc last week | 05:15 |
| wallyworld_ | about returning nil if the json failed | 05:15 |
| davecheney | ok, i don't want to get into that | 05:15 |
| wallyworld_ | me either :-) | 05:15 |
| wallyworld_ | just providing context | 05:15 |
| wallyworld_ | as to why it is a pointer | 05:16 |
| davecheney | if we break down the for loop, what is happening behind hte scenes you're getting | 05:16 |
| davecheney | var server Nova.server | 05:16 |
| davecheney | for i := 0 ; i < len(*servers); i++ { | 05:16 |
| davecheney | server = *servers[j] | 05:16 |
| davecheney | ... then your code | 05:16 |
| davecheney | } | 05:16 |
| davecheney | (this is part of the explanation) | 05:17 |
| wallyworld_ | *servers[i]? | 05:17 |
| davecheney | do you agree that this can be subtituted for the range above | 05:17 |
| wallyworld_ | yes | 05:17 |
| wallyworld_ | with the i | 05:17 |
| davecheney | yes, sorry | 05:17 |
| wallyworld_ | np, just making sure | 05:17 |
| davecheney | so inside each loop iteration it becomes | 05:17 |
| davecheney | server = *servers[i] (hidden) | 05:18 |
| davecheney | insts = append(insts, &instance{e, &server}) | 05:18 |
| davecheney | &server is capturing the address of the local server variable every time | 05:19 |
| davecheney | the same local server variable | 05:19 |
| davecheney | which is why they all end up as the last value assigned to it | 05:19 |
| * wallyworld_ thinks | 05:20 | |
| wallyworld_ | davecheney: so by doing s:= server, it forces a copy to be made? | 05:21 |
| davecheney | yes | 05:21 |
| wallyworld_ | ok, i think i get it. is the moral of the story not to use loop variables in certain circumstances? | 05:22 |
| davecheney | when taking their address | 05:22 |
| davecheney | sadly this is just one thing you have to be ever vigilant for | 05:22 |
| wallyworld_ | right, ok. thanks so much. i wasted a loooong time on this | 05:23 |
| davecheney | sorry, it is one of the rights of passage | 05:23 |
| wallyworld_ | lol | 05:23 |
| wallyworld_ | i still don't feel like Go is "native" just yet, but it's getting there | 05:24 |
| davecheney | that's good to hear | 05:24 |
| davecheney | i'm constantly amazed at how quickly can pick up the language | 05:24 |
| davecheney | it tells me it's doing something right | 05:24 |
| wallyworld_ | yeah, there's some stuff i don't like, but it's interesting to work with | 05:25 |
| davecheney | wallyworld_: btw, do you feel that any sort of decision was reached about the 'when and how should we meet' discussion ? | 05:25 |
| davecheney | in the meeting I got the impression, and looking at the notes, that the decision to not change anything was made | 05:25 |
| wallyworld_ | my understanding was alternating times 21:00UTC and 09:00UTC | 05:25 |
| davecheney | then the day after Mark posted an email saying we're going to do that | 05:25 |
| davecheney | alternating times ?! | 05:26 |
| davecheney | i read that as two meetings | 05:26 |
| wallyworld_ | it was explained to me as alternating and you would make whichever meeting you could | 05:26 |
| wallyworld_ | or both | 05:26 |
| davecheney | but, alternating every other week ? | 05:26 |
| wallyworld_ | yes | 05:26 |
| wallyworld_ | unless i am mistaken | 05:27 |
| davecheney | so we can go an entire milestone cycle without meeting or feedback ? | 05:27 |
| wallyworld_ | is each milestone cycle 2 weeks? | 05:27 |
| wallyworld_ | i think for you and me we can make both | 05:27 |
| davecheney | you can see we run a pretty loose ship on juju-core, but yes, ish | 05:27 |
| wallyworld_ | to be honest, the current one that is 10pm for me i can make most weeks | 05:28 |
| davecheney | it's 11pm for me | 05:28 |
| wallyworld_ | yeah, DST :-) | 05:28 |
| davecheney | and i'm getting pressure from home | 05:28 |
| wallyworld_ | which i guess is why they changed it | 05:28 |
| wallyworld_ | timezones suck sometimes | 05:29 |
| wallyworld_ | happy wife, happy life | 05:29 |
| wallyworld_ | i'm not sure if tomorrow's meeting is still at 0pm, will have to check | 05:29 |
| davecheney | DST is bitch if you need to coordinate with western europe | 05:33 |
| davecheney | 7pm UK time is 6am AEST | 05:33 |
| davecheney | (or is that AEDT | 05:33 |
| wallyworld_ | i thought it was 7am AEST | 05:34 |
| davecheney | nup | 05:35 |
| davecheney | http://everytimezone.com/ | 05:35 |
| wallyworld_ | not 7pm, 9pm | 05:35 |
| wallyworld_ | 21:00UTC | 05:35 |
| wallyworld_ | so +10 is 7am for me | 05:35 |
| TheMue | Morning | 06:50 |
| davecheney | morning | 06:51 |
| TheMue | davecheney: Had a nice weekend? | 06:51 |
| === TheMue_ is now known as TheMue | ||
| rogpeppe2 | morning all | 08:34 |
| === rogpeppe2 is now known as rogpeppe | ||
| TheMue | Hiya rogpeppe | 08:40 |
| fwereade | rogpeppe, TheMue, heyhey | 08:45 |
| fwereade | rogpeppe, TheMue: I would appreciate your opinions on the Living interface | 08:45 |
| TheMue | fwereade: Hi | 08:45 |
| rogpeppe | 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 |
| fwereade | rogpeppe, TheMue: it only seems to be used for the tests | 08:46 |
| fwereade | rogpeppe, TheMue: and I have slight concern that it doesn't really fit our needs | 08:46 |
| rogpeppe | fwereade: what CL are we talking about? | 08:46 |
| fwereade | rogpeppe, it's a piece that's already in place | 08:47 |
| rogpeppe | fwereade: ah | 08:47 |
| fwereade | rogpeppe, state/life.go | 08:47 |
| fwereade | rogpeppe, it has EnsureDying/EnsureDead | 08:47 |
| rogpeppe | fwereade: you're objecting to those methods? | 08:47 |
| fwereade | rogpeppe, we took those methods off Relation because they didn't make sense | 08:47 |
| TheMue | 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 |
| fwereade | rogpeppe, and while they're ok for unit they don't express enough | 08:48 |
| rogpeppe | fwereade: do you think Unit needs a richer interface than a simple "EnsureDead"? | 08:48 |
| rogpeppe | fwereade: or EnsureDying | 08:49 |
| fwereade | rogpeppe, yeah -- remove-unit --force | 08:49 |
| fwereade | 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:49 |
| rogpeppe | fwereade: ah, so EnsureDying isn't allowed to take account of things that might block the EnsureDying | 08:50 |
| fwereade | rogpeppe, yeah, nothing should block an EnsureDying | 08:50 |
| rogpeppe | fwereade: emr | 08:50 |
| fwereade | rogpeppe, depending on the circumstances, the existence of subordinates may or may not want to block EnsureDead | 08:50 |
| rogpeppe | erm | 08:50 |
| rogpeppe | fwereade: istm that EnsureDying *is* a way to say, politely, "please kill yourself" | 08:51 |
| rogpeppe | fwereade: and that EnsureDead *is* a way to force dead immediately | 08:51 |
| TheMue | rogpeppe: That's how I understood it too. | 08:51 |
| fwereade | rogpeppe, yes... we have 3 things to express, and 2 0-arg methods | 08:51 |
| rogpeppe | fwereade: that doesn't sound like the current interface is wrong, but that some things may need more | 08:52 |
| fwereade | rogpeppe, maybe | 08:53 |
| TheMue | fwereade: Please match the current methods to your three sentences above to make sure which one you don't see covered. | 08:53 |
| fwereade | rogpeppe, bear in mind that it was already dropped from relation because it's useless | 08:53 |
| rogpeppe | fwereade: how do you remove a relation then? | 08:54 |
| fwereade | rogpeppe, TheMue: EnsureDying=please kill yourself, EnsureDead=die immediately; no way to politely signal your own death | 08:54 |
| fwereade | rogpeppe, it depends | 08:54 |
| fwereade | rogpeppe, I ca dredge up the details if you like | 08:54 |
| rogpeppe | fwereade: by "signal your own death", do you mean there's no way to tell others when you've died? | 08:55 |
| fwereade | rogpeppe, there is no convenient way for me to coordinate the unit's death amongst various tasks | 08:55 |
| TheMue | 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 |
| rogpeppe | fwereade: i'm not sure what you mean by that | 08:55 |
| fwereade | rogpeppe, ok, maybe I should shift perspective around and see what sorts of statements we agree on | 08:57 |
| fwereade | rogpeppe, the only thing that can sanely set a machine to Dead is a machine agent; agreed? | 08:57 |
| fwereade | rogpeppe, and the only thing that can sanely set it to Dying is the user | 08:57 |
| TheMue | fwereade: How would you name that third method? And who will call it? | 08:58 |
| rogpeppe | fwereade: i'm not sure. what if the machine has gone away and isn't coming back? | 08:58 |
| fwereade | rogpeppe, do you mean the "instance" | 08:58 |
| rogpeppe | fwereade: yeah | 08:58 |
| fwereade | rogpeppe, I don't think that's relevant then? | 08:58 |
| fwereade | rogpeppe, juju will provision a new one and put the machine agent on it | 08:58 |
| rogpeppe | fwereade: do we have to resurrect the instance and its machine agent in order to kill the Machine? | 08:59 |
| * 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 | |
| TheMue | s/to to/to do/ | 09:00 |
| fwereade | rogpeppe, you're talking like we can *stop* juju from provisioning a new instance for a broken machine? | 09:00 |
| fwereade | TheMue, ok | 09:01 |
| fwereade | TheMue, what does service.EnsureDead do? | 09:01 |
| fwereade | 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 |
| TheMue | fwereade: It sets the entity to dead. | 09:02 |
| fwereade | 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 |
| fwereade | TheMue, ok, and what happens when you do that? | 09:03 |
| fwereade | TheMue, and more to the point, when is it ok to do that? | 09:04 |
| rogpeppe | fwereade: what if an instance goes down and the user calls terminate-machine before it's been reprovisioned? | 09:04 |
| TheMue | 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 |
| fwereade | rogpeppe, if we can detect that for sure, then we can remove it; no reason to make it dead | 09:05 |
| fwereade | TheMue, think through what will happen if we set a service to Dead | 09:05 |
| fwereade | TheMue, what should happen to the units of that service? | 09:05 |
| TheMue | fwereade: I'm currently looking from a more abstracte perspective about where methods have to apply. | 09:05 |
| rogpeppe | fwereade: doesn't it have to be dead before we remove it? | 09:05 |
| fwereade | rogpeppe, not at all, we don't do that with relations | 09:06 |
| TheMue | fwereade: IMHO they should be set to dead too, before the service is marked as dead. | 09:06 |
| fwereade | rogpeppe, I'm not sure the Dead state is even meaningful for relations or services | 09:06 |
| fwereade | TheMue, how will you craft your request to set 100k units to Dead? | 09:06 |
| TheMue | 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 |
| fwereade | TheMue, using the txn package, remember | 09:08 |
| fwereade | TheMue, logically, yes | 09:08 |
| fwereade | TheMue, but there are 2 possibilities here | 09:08 |
| fwereade | TheMue, we can set services to dead, and get crack, or wee can admit that service.EnsureDead is (probably) crack | 09:08 |
| rogpeppe | 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:08 |
| rogpeppe | fwereade: are you saying that if we set something to dead, we may as well just remove it? | 09:09 |
| fwereade | rogpeppe, ok, so machines are easy: Dying from outside, Dead from inside | 09:09 |
| TheMue | rogpeppe: Do we mix topics here? | 09:09 |
| fwereade | 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 |
| fwereade | rogpeppe, units and machines *do* have a use for the dead state | 09:10 |
| * 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 | |
| fwereade | 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 |
| fwereade | TheMue, what we do is set the service to Dying | 09:11 |
| fwereade | TheMue, every unit is the responsible for setting itself to dying and cleaning itself up | 09:11 |
| fwereade | TheMue, the units' deployer waits for it to become dead | 09:12 |
| TheMue | fwereade: Is every unit watching it's services' lifecycle? | 09:12 |
| fwereade | TheMue, yes | 09:12 |
| TheMue | fwereade: Ah, ok, missed that, thanks. | 09:12 |
| rogpeppe | fwereade: it sounds like you're arguing for removing EnsureDead | 09:13 |
| fwereade | sorry 1 sec | 09:13 |
| fwereade | 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 |
| fwereade | TheMue, to continue: then the deployer removes the unit | 09:13 |
| TheMue | fwereade: And markes it as dead? | 09:14 |
| fwereade | TheMue, the unit marked itself as dead | 09:14 |
| fwereade | TheMue, the deployer is then responsible for uninstalling it and removing it from state | 09:14 |
| TheMue | fwereade: How does it mark itself as dead? | 09:14 |
| fwereade | TheMue, and removing its service from state if it was the last member of a dying unit | 09:14 |
| fwereade | TheMue, at the moment it calls EnsureDead | 09:15 |
| TheMue | fwereade: The unit calls EnsureDead() on itself? Aha. | 09:15 |
| fwereade | TheMue, but this will not work correctly in the presence of subordinates | 09:15 |
| fwereade | TheMue, yes | 09:15 |
| fwereade | TheMue, in general only an entity is meant to declare itself dead | 09:15 |
| TheMue | fwereade: Could you give me a hint where in the code this happens? | 09:16 |
| fwereade | TheMue, the EnsureDead? worker/uniter/modes.go | 09:16 |
| fwereade | TheMue, ModeStop or something? ModeDie? | 09:16 |
| TheMue | fwereade: So the uniter calls it, not the unit. | 09:16 |
| fwereade | TheMue, what part of the unit has its own volition if not the uniter? | 09:16 |
| rogpeppe | back in a mo | 09:16 |
| TheMue | 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:17 |
| fwereade | TheMue, sure, sorry, I didn't mean to be unclear | 09:18 |
| TheMue | fwereade: I only wanted to clear that to not be confused. | 09:18 |
| TheMue | fwereade: I never been deep in the uniter. So that's important to me to get a similar context. | 09:18 |
| fwereade | TheMue, I think of a Unit as a dumb type manipulated by interesting clients -- the clients are the agents and the command line | 09:18 |
| rogpeppe | back | 09:19 |
| TheMue | fwereade: OK, now it's more clear, thanks. | 09:19 |
| fwereade | 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 |
| fwereade | rogpeppe, and it sounds like exactly the same problem as the uniter has | 09:20 |
| rogpeppe | fwereade: is the provisioner right to allocate a new instance for a machine that's set to dying? | 09:20 |
| fwereade | rogpeppe, if it's still meant to be running a unit, yes, unless you have a better idea | 09:21 |
| fwereade | rogpeppe, but I forget: did we agree that we couldn't set a machine to dying until it had no assigned units? | 09:21 |
| rogpeppe | fwereade: i thought we could always set something to *dying* | 09:22 |
| fwereade | 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:22 |
| rogpeppe | fwereade: i have a suspicion we have some muddy thinking about the machine/instance/unit relationship | 09:23 |
| fwereade | rogpeppe, ok, so terminate-machine shouldn't actually terminate the machine? | 09:23 |
| fwereade | rogpeppe, ok, please explain your view of the situation | 09:24 |
| fwereade | rogpeppe, is it your position that terminate-machine should also terminate all the units on that machine? | 09:24 |
| rogpeppe | 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 |
| fwereade | 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:24 |
| rogpeppe | fwereade: ok, well that sounds reasonable | 09:25 |
| fwereade | rogpeppe, ok, you know what? this makes me question EnsureDying/EnsureDead still more | 09:25 |
| rogpeppe | 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 |
| rogpeppe | fwereade: when the provisioner notices that the instance is dead, should it allocate another one? | 09:26 |
| rogpeppe | fwereade: i don't see any question about EnsureDying | 09:27 |
| rogpeppe | fwereade: EnsureDead seems to be the problematic part of the interface | 09:28 |
| fwereade | rogpeppe, ok, what does it do? | 09:29 |
| fwereade | rogpeppe, please describe the chain of consequences from EnsureDying | 09:29 |
| rogpeppe | fwereade: the provisioner can see when an instance dies, right? | 09:30 |
| fwereade | rogpeppe, yeah, I think so, roughly | 09:31 |
| rogpeppe | fwereade: (i'm not actually sure that it can, tbh, but this we seem to believe it) | 09:31 |
| rogpeppe | s/this we/we/ | 09:31 |
| fwereade | rogpeppe, I think it s possible to infer it anyway | 09:31 |
| rogpeppe | fwereade: i'm not sure it is | 09:31 |
| rogpeppe | fwereade: in the presence of network failures | 09:31 |
| rogpeppe | fwereade: anyway, assuming we can | 09:32 |
| rogpeppe | fwereade: when the provisioner sees an instance go down, it allocates a new one and assigns the old Machine to it, right? | 09:32 |
| fwereade | rogpeppe, yeah | 09:32 |
| rogpeppe | fwereade: so if someone has called EnsureDying on that machine, should the provisioner really allocate a new instance for the machine? | 09:33 |
| rogpeppe | fwereade: (surely not?!) | 09:33 |
| fwereade | rogpeppe, if a machine is Dying it means "I will set myself to Dead when I have disacharged my responsibilities" | 09:34 |
| rogpeppe | fwereade: what is a machine without an instance? | 09:34 |
| fwereade | rogpeppe, I am reluctant to stipulate that the machine agent can die with no responsibilities undischarged | 09:35 |
| rogpeppe | fwereade: what responsibilities does a machine agent have if it has no units? | 09:35 |
| fwereade | rogpeppe, I suspect storage handling will come into play mostly at the machine agent level | 09:36 |
| fwereade | rogpeppe, but, ok -- that's a potential derail | 09:37 |
| rogpeppe | fwereade: i just think it's weird that we'd allocate a new instance only to shut it down immediately | 09:37 |
| fwereade | rogpeppe, what you say makes sense, but you're not taking it far enough | 09:37 |
| rogpeppe | fwereade: i think the provisioner can proxy for the machine agent in this instance | 09:37 |
| fwereade | 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 |
| fwereade | rogpeppe, it means Dying is not a sane state for a Machine to have | 09:38 |
| fwereade | rogpeppe, it will become so if/when we change the rules ofc... | 09:39 |
| rogpeppe | fwereade: sorry, you're mixing up machine dying and unit dying in a way i don't quite understand | 09:39 |
| fwereade | rogpeppe, shit sorry s/unit/machine/ | 09:40 |
| fwereade | s/unit agent/machine/ actually | 09:40 |
| rogpeppe | fwereade: it sounds reasonably sane to me | 09:40 |
| fwereade | rogpeppe, what is the distinction between Dying and Dead for a machine? | 09:41 |
| rogpeppe | fwereade: i think it's a pity we haven't actually implemented terminate-machine yet... | 09:42 |
| fwereade | 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 |
| fwereade | rogpeppe, but I'm actually questioning it | 09:43 |
| rogpeppe | 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 |
| rogpeppe | fwereade: anyone can set a machine to dying at any time | 09:44 |
| fwereade | rogpeppe, ok, well then that is surely crack | 09:44 |
| fwereade | rogpeppe, why timebomb your machines like that? | 09:44 |
| rogpeppe | fwereade: i'm not sure why | 09:44 |
| rogpeppe | fwereade: you might have a good reason | 09:45 |
| rogpeppe | fwereade: you might not want a new machine to be allocated | 09:45 |
| fwereade | 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 |
| rogpeppe | fwereade: so calling terminate-machine before removing a unit means that we can ensure that's true | 09:45 |
| rogpeppe | fwereade: that seems quite plausibly useful to me | 09:46 |
| fwereade | rogpeppe, but you're also suggesting that the unit should get no opportunity to shut down cleanly if the instance goes away | 09:46 |
| fwereade | rogpeppe, it's a total niche case | 09:46 |
| fwereade | rogpeppe, defaulting to shutting down machines when unused would be moreuseful | 09:46 |
| fwereade | rogpeppe, weeks-delayed kill commands are pretty esoteric ;) | 09:46 |
| rogpeppe | 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 |
| fwereade | 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:47 |
| fwereade | rogpeppe, my point is that if we're going to get clever about machine termination, delayed-kill is not the top priority | 09:48 |
| rogpeppe | fwereade: well maybe, but there is overhead in starting an instance, and state in an instance that may not be easily stored. | 09:48 |
| rogpeppe | fwereade: i think it falls out naturally from our model. | 09:48 |
| fwereade | rogpeppe, yeah, depends on the provider | 09:48 |
| rogpeppe | fwereade: and it *is* potentially useful behaviour | 09:49 |
| fwereade | rogpeppe, it is potentially useful behaviour that we should restrain ourselves from implementing until we understand the use cases | 09:49 |
| fwereade | rogpeppe, you know what | 09:51 |
| fwereade | rogpeppe, Unit.EnsureDead, implemented correctly, is just *horribly* complex | 09:52 |
| rogpeppe | fwereade: because it's hard to check all the unit's dependencies before setting state to dead? | 09:53 |
| fwereade | rogpeppe, it needs to clean up some or all of: machine assignment, subordinates Dead-setting, relation removal, and service removal | 09:53 |
| fwereade | rogpeppe, if we do it correctly, we have to just build up some monster transaction | 09:53 |
| fwereade | rogpeppe, not to mention just cleaning up relation membership | 09:54 |
| rogpeppe | fwereade: that's not Unit.EnsureDead - that's RemoveUnit | 09:54 |
| rogpeppe | fwereade: EnsureDead and EnsureDying don't do anything other than set life state | 09:54 |
| fwereade | rogpeppe, ok, drop service removal | 09:54 |
| fwereade | rogpeppe, that's the only one | 09:54 |
| rogpeppe | fwereade: it's up to the caller to make sure that the other invariants are preserved correctly. | 09:55 |
| fwereade | rogpeppe, ha ha | 09:55 |
| fwereade | rogpeppe, how is that possible? | 09:55 |
| rogpeppe | fwereade: well usually we do that be not allowing new things to be added when something is in a dying state. | 09:56 |
| fwereade | rogpeppe, to make sane transitions in system state we have to do these things as single transactions | 09:56 |
| Aram | good morning | 09:56 |
| rogpeppe | Aram: hiya! | 09:56 |
| fwereade | Aram, heyhey | 09:56 |
| fwereade | Aram, nice holiday? | 09:56 |
| Aram | yeah. | 09:56 |
| fwereade | Aram, cool | 09:56 |
| rogpeppe | Aram: is your holiday finished now? | 09:57 |
| Aram | yeah. | 09:57 |
| fwereade | Aram, I landed your watchers -- we've identified the firewaller bug and TheMue is looking into it this week AIUI | 09:57 |
| TheMue | fwereade, Aram: +1 | 09:57 |
| Aram | fwereade, could you please link me to the commit that fixed it? | 09:57 |
| TheMue | Aram: Hello btw. | 09:57 |
| Aram | hi. | 09:57 |
| rogpeppe | fwereade: i'm not sure we do need to do these things as single transactions | 09:58 |
| rogpeppe | fwereade: and that's why we have the dying/dead distinction | 09:58 |
| fwereade | rogpeppe, Dying/Dead is about handover of responsibility surely | 09:58 |
| TheMue | Aram: It's not yet fixed, only better identified. I'm now working on it with two CLs. | 09:58 |
| fwereade | rogpeppe, but any time we want to make a change to the state, we need to do it as a single transation | 09:59 |
| fwereade | rogpeppe, or write a CA | 09:59 |
| rogpeppe | fwereade: CA? | 09:59 |
| fwereade | rogpeppe, Corrective Agent ;) | 09:59 |
| rogpeppe | fwereade: ha | 09:59 |
| TheMue | Aram: And LXC is right now stopped, one CL has gone in, two are open. MAAS has gotten higher priority. | 09:59 |
| rogpeppe | fwereade: but that's not true. we don't need to make every change to the state as a single transaction | 09:59 |
| Aram | fwereade, I've seen a proposal to replace int with string, excellent. | 09:59 |
| fwereade | Aram, (there was a MUW bug that was contributing to that test failing, I'll find that commit, just a mo) | 10:00 |
| rogpeppe | 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 |
| rogpeppe | fwereade: or set it to dead | 10:00 |
| Aram | meh, the damn unity panel can't be set in a different position, and auto hide doesn't work in vmware. | 10:01 |
| rogpeppe | Aram: so run ubuntu natively :-) | 10:03 |
| Aram | I bought a new mac. | 10:07 |
| TheMue | Aram: It's possible to auto-hide it, have to find the switch again. Somwhere in the settings. | 10:08 |
| Aram | TheMue, it's possible to auto hide it, it's impossible to appear again after you've done so. | 10:09 |
| Aram | that's because compiz is too smart for its own good. | 10:09 |
| TheMue | *lol | 10:09 |
| Aram | it calculates how hard you've hit the screen edge. | 10:09 |
| Aram | since vmware won't deliver mouse events after you've hit the edge, it can't calculate how hard you hit it. | 10:10 |
| Aram | so it won't show up. | 10:10 |
| === Aram2 is now known as Aram | ||
| fwereade | so, hey again all | 11:00 |
| rogpeppe | fwereade: your network connection die? | 11:01 |
| fwereade | rogpeppe, power cut | 11:01 |
| rogpeppe | fwereade: ah, not useful | 11:01 |
| fwereade | rogpeppe, didn't last long :0 | 11:02 |
| fwereade | rogpeppe, ok, so, the trouble with lifecycle discussions is that there are in the end fewer commonalities than one might think | 11:05 |
| rogpeppe | fwereade: did you see my last commend ("... or set it to dead")? | 11:05 |
| rogpeppe | comment | 11:05 |
| fwereade | rogpeppe, ah, sorry, I didn't | 11:05 |
| rogpeppe | fwereade: ah | 11:05 |
| rogpeppe | [09:59:49] <rogpeppe> fwereade: but that's not true. we don't need to make every change to the state as a single transaction | 11:05 |
| rogpeppe | [10:00:36] <rogpeppe> 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:05 |
| rogpeppe | [10:00:42] <rogpeppe> fwereade: or set it to dead | 11:06 |
| fwereade | rogpeppe, ok, so what's the scenario you're considering there? | 11:06 |
| rogpeppe | 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 |
| fwereade | 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 |
| fwereade | rogpeppe, I think :) | 11:07 |
| fwereade | rogpeppe, who is setting the unit to dying, and why? | 11:07 |
| rogpeppe | fwereade: i was talking about setting the unit to dead, not dying | 11:08 |
| rogpeppe | fwereade: anyone can set the unit to dying | 11:08 |
| mramm | 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 |
| rogpeppe | mramm: i guess you'll miss the meeting then | 11:08 |
| mgz | dimitern: want to catch up, even though it'll only be us two? | 11:08 |
| mramm | rogpeppe: yea | 11:08 |
| mramm | rogpeppe: I also need to figure out better meeting times | 11:09 |
| fwereade | 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 |
| fwereade | rogpeppe, but the tricky case is EnsureDead from the outside | 11:09 |
| rogpeppe | 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 |
| rogpeppe | fwereade: which is usually the agent responsible for the object, but may not be, in some cases. | 11:10 |
| fwereade | rogpeppe, ok, so when someone uses remove-unit --force... | 11:11 |
| fwereade | rogpeppe, that client is basically taking on all the responsibilities of the unit agent, right? | 11:11 |
| rogpeppe | fwereade: i'm not sure | 11:11 |
| fwereade | rogpeppe, well, the UA won't do anything else after it's dead | 11:12 |
| rogpeppe | fwereade: i don't think the client can call EnsureDead in that case | 11:12 |
| dimitern | mgz: sure, i'm starting mumble now | 11:12 |
| fwereade | rogpeppe, its responsibilities must either be transferred elsewhere, or discharged, in the same transaction that makes it Dead | 11:12 |
| rogpeppe | fwereade: i think it just means "unit: please remove yourself regardless of the dependencies" | 11:12 |
| fwereade | rogpeppe, I don't think there's any command that means "please corrupt state" | 11:13 |
| rogpeppe | fwereade: i don't see why it all needs to happen in the same transaction | 11:13 |
| fwereade | rogpeppe, ok, so what happens when the first change is made and then the connection is dropped? | 11:13 |
| rogpeppe | 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 |
| rogpeppe | s/"force"/"force",/ | 11:14 |
| fwereade | rogpeppe, please expand on what you mean by "kill itself" | 11:15 |
| fwereade | rogpeppe, it needs to exit the relations even if it isn't running hooks | 11:15 |
| rogpeppe | fwereade: well, perhaps it might be good if you could explain the sematics of remove-unit --force. | 11:15 |
| fwereade | rogpeppe, the idea was from possibly the first lisbon | 11:16 |
| rogpeppe | semantics | 11:16 |
| fwereade | rogpeppe, make the unit Dead | 11:17 |
| fwereade | rogpeppe, the trouble is that "make the unit Dead" is not necessarily a simple change to state | 11:17 |
| rogpeppe | fwereade: at a higher level, why do we want this? | 11:17 |
| fwereade | rogpeppe, because a broken UA is a hugely awful failure, that otherwise blocks the removal of machines, services, and relations | 11:17 |
| fwereade | rogpeppe, it's a feature we hope nobody will use | 11:18 |
| rogpeppe | fwereade: ok. are we talking about a broken unit agent, or a dead instance? | 11:18 |
| fwereade | rogpeppe, a broken unit agent | 11:18 |
| fwereade | rogpeppe, that has bad code, and bad upgrading code too, and that we have no other way of removing | 11:18 |
| rogpeppe | fwereade: so if we know it's broken, then we know we can act for it, right? | 11:19 |
| fwereade | rogpeppe, sure, I'm 100% comfortable with the idea that we can tak on its responsibilities | 11:19 |
| fwereade | rogpeppe, I'm just saying that if we do so we must either discharge them all, or transfer responsibility for doing so elsewhere, and that it must be done in the same transaction as that in which we set the unit to dead | 11:20 |
| rogpeppe | fwereade: ok, so something else must take on its responsibilities for a while and see the unit through its last phases. | 11:20 |
| fwereade | rogpeppe, so you want two different sorts of Dying state | 11:20 |
| rogpeppe | fwereade: i still don't see that last point | 11:20 |
| rogpeppe | fwereade: no, i don't | 11:21 |
| fwereade | rogpeppe, we are talking about setting the unit to dead | 11:21 |
| fwereade | rogpeppe, there are a potentially large number of things in state that need to be changed in order for the unit to become dead and state to remain consistent | 11:21 |
| rogpeppe | fwereade: i thought we were talking about forcing the unit to die even when its agent is broken | 11:21 |
| rogpeppe | fwereade: that's a somewhat different thing | 11:22 |
| fwereade | rogpeppe, er, "setting the unit to dead" is what the unit agent would have done were it not broken, right? | 11:22 |
| rogpeppe | fwereade: i suspect we might want another worker/agent to manage this | 11:22 |
| fwereade | rogpeppe, the whole point is setting it to dead | 11:22 |
| fwereade | rogpeppe, that is how we communicate that the unit agent can be safely trashed | 11:23 |
| rogpeppe | fwereade: well, presumably the unit agent will manage the "potentially large number of things" along the road to deadness, yes? | 11:23 |
| rogpeppe | fwereade: setting it to dead indicates that the unit agent *is already* trashed | 11:23 |
| fwereade | rogpeppe, when we set Dying, that is exactly what the uniter does, yes | 11:23 |
| fwereade | rogpeppe, not even slightly | 11:23 |
| fwereade | rogpeppe, setting it to dead is what lets its deployer know that it can be trashed | 11:24 |
| rogpeppe | fwereade: ok, so we need something else to take on the responsibility for the work that the unit agent normally does | 11:24 |
| fwereade | rogpeppe, <fwereade> rogpeppe, its responsibilities must either be transferred elsewhere, or discharged, in the same transaction that makes it Dead | 11:24 |
| rogpeppe | fwereade: ok, that's a different level of trashing | 11:24 |
| fwereade | rogpeppe, ok: AIUI the deployer is responsible for both kinds | 11:25 |
| fwereade | rogpeppe, once something is Dead, the thing responsible for it releases any underlying resources and removes it from state | 11:25 |
| rogpeppe | fwereade: AFAICS the deployer is responsible for maintaining the container of the unit | 11:25 |
| rogpeppe | fwereade: yes | 11:26 |
| rogpeppe | fwereade: and that's not the problem. the problem is the transition to death | 11:26 |
| fwereade | rogpeppe, to Dead? | 11:26 |
| rogpeppe | fwereade: yeah | 11:26 |
| fwereade | rogpeppe, yes | 11:26 |
| rogpeppe | fwereade: and we can't solve that by simply charging in and calling EnsureDead | 11:27 |
| fwereade | rogpeppe, depending on what EnsureDead means, bu yes | 11:27 |
| rogpeppe | fwereade: but i don't see that it must all be called in the same transaction either | 11:27 |
| mramm | hotel wifi at 25% packet loss :( | 11:27 |
| fwereade | rogpeppe, it sounds like yu are advocating for a corrective agent | 11:28 |
| fwereade | rogpeppe, or task | 11:28 |
| rogpeppe | fwereade: perhaps you could outline the things that the unit agent does after seeing Dying and before it calls EnsureDead? | 11:29 |
| fwereade | rogpeppe, depart all its relations, basically | 11:29 |
| rogpeppe | fwereade: perhaps; i'm not sure yet. | 11:29 |
| fwereade | rogpeppe, this is not necessarily a simple operation | 11:29 |
| rogpeppe | fwereade: each relation depart can be done as a single transaction? | 11:29 |
| fwereade | rogpeppe, because some of those relations might themselves be dying | 11:29 |
| fwereade | rogpeppe, yes, they could | 11:30 |
| rogpeppe | fwereade: so esssentially it does: for r in relations {r.Depart()}; u.EnsureDead() ? | 11:30 |
| fwereade | rogpeppe, you are proposing that we depart them each individually, and assuming that the unit agent is not currently running and will never come back? | 11:31 |
| fwereade | rogpeppe, remove-unit --force needs to work even if the UA suddenly wakes up | 11:31 |
| fwereade | rogpeppe, while the unit is not dead, the UA has responsibility for it | 11:31 |
| rogpeppe | fwereade: if relation departing is idempotent, i think that could work | 11:32 |
| fwereade | rogpeppe, I am open to discussion re when/how that responsibility is transferred/discharged | 11:32 |
| mramm2 | hotel wifi at 25% packet loss, falling back to cell phone data plan but on edge network, so only a half step above IPoAC | 11:33 |
| fwereade | rogpeppe, I don't think so -- I can imagine a path by which the UA could rejoin one of those relations in between the depart and the ensuredead | 11:33 |
| rogpeppe | fwereade: can a UA rejoin a relation when the unit is marked as dying? | 11:33 |
| fwereade | rogpeppe, why would the unit be marked as dying? | 11:33 |
| rogpeppe | fwereade: isn't that one of the transaction guards? | 11:33 |
| fwereade | rogpeppe, we're talking about forcing Dead from any state | 11:34 |
| rogpeppe | fwereade: because that's the first thing we must do when calling remove-unit --force, surely? | 11:34 |
| rogpeppe | fwereade: that's how we manage to shut down cleanly in multiple transactions | 11:34 |
| fwereade | rogpeppe, I guess that's probably not too harmful, although I am strongly -1 on state changes that are not expressed as single transactions | 11:36 |
| niemeyer | fwereade: How would the deployer even know to kill the unit if it wasn't market as dying | 11:37 |
| niemeyer | Good mornings, btw | 11:37 |
| fwereade | niemeyer, heyhey | 11:37 |
| TheMue | niemeyer: Morning | 11:37 |
| fwereade | niemeyer, the deployer removes the unit's it's responsible for when they become Dead | 11:37 |
| fwereade | niemeyer, they shouldn't care that their units are Dying | 11:37 |
| fwereade | sorry errant ' | 11:37 |
| niemeyer | fwereade: Ah, right, okay | 11:38 |
| fwereade | niemeyer, Dying is a signal to the UA to clean itself up and mark itself Dead when it's ready | 11:38 |
| niemeyer | fwereade: Yeah, you're right.. something else has to mark it as Dead in that edge case being debated | 11:38 |
| fwereade | niemeyer, yeah, and the requirements for the two cases are rather different, so a single EnsureDead method with no parameters is not enough to express what we need to do | 11:40 |
| rogpeppe | fwereade: if we want it to be expressed as a single transaction, then we need an agent to do the rest for us | 11:41 |
| rogpeppe | fwereade: call it the CA if you want | 11:41 |
| fwereade | niemeyer, in a clean shutdown, the uniter shouldn't set itself to Dead until it has no remaining subordinates | 11:41 |
| fwereade | niemeyer, in a forced death, we need to make all the subordinates dead as well, I think -- but I guess that is a red herring, it's just where I started the conversation from | 11:42 |
| rogpeppe | fwereade: i don't think that remove-unit --force should simply call EnsureDead to do the work | 11:42 |
| fwereade | niemeyer, the relations question is much more interesting | 11:42 |
| niemeyer | fwereade: It's an interesting case, actually | 11:43 |
| fwereade | rogpeppe, ok, sorry, I have been talking a lot | 11:43 |
| fwereade | rogpeppe, would you outline how how would expect the feature to work? | 11:43 |
| fwereade | s/how how/how you/ | 11:43 |
| rogpeppe | fwereade: i'd expect the forced shutdown to go through the same phases as a non-forced shutdown | 11:44 |
| rogpeppe | fwereade: and i would expect it to error out if the agent involved is actually alive. | 11:44 |
| fwereade | rogpeppe, ok, but when the unit is Dying its agent is still the responsible entity | 11:44 |
| rogpeppe | fwereade: mebbe | 11:44 |
| fwereade | rogpeppe, shouldn't remove-unit --force be able to forcibly remove the unit whatever it's doing? | 11:45 |
| rogpeppe | fwereade: yeah, probably | 11:45 |
| rogpeppe | fwereade: in which case we need to make the shutdown phases work even when multiple entities are performing them | 11:45 |
| niemeyer | fwereade: It should, but if that's done when the unit is not even dying, it feels like we should do something to not create unnecessary harm | 11:46 |
| fwereade | rogpeppe, well, we should have been doing so anyway, right, what with the txn runners | 11:46 |
| rogpeppe | fwereade: yes, except you were saying you can't do it all in one transaction. which seems a reasonable issue. | 11:47 |
| fwereade | niemeyer, rogpeppe: yeah, I think it's fine to start remove-unit --force by setting Dying | 11:47 |
| niemeyer | fwereade: and having a grace period, maybe | 11:48 |
| fwereade | niemeyer, rogpeppe: I think it's ok to have remove-unit always set the unit to Dying | 11:49 |
| rogpeppe | niemeyer: that, presumably, would mean that remove-unit --force would need to take as long as that grace period... or we'd need an agent to do it. | 11:49 |
| niemeyer | rogpeppe: Assuming the unit wasn't already Dying | 11:49 |
| fwereade | niemeyer, rogpeppe: and then if --force is set, aggressively go around trashing its stuff until it can call EnsureDead (or finds that the unit has done so itself) | 11:49 |
| rogpeppe | fwereade: that's what i'm thinking | 11:49 |
| rogpeppe | niemeyer: if it is already dying, we ignore the grace period? | 11:50 |
| niemeyer | rogpeppe: Yeah, I think that sounds reasonable | 11:50 |
| fwereade | niemeyer, I rather feel that the grace period is unnecessary -- if we're forcing then we're stating that we don't want or need a clean shutdown, we just want it gone | 11:50 |
| rogpeppe | niemeyer: it seems slightly odd that. {remove-unit; remove-unit --force} is different from {remove-unit --force} | 11:51 |
| niemeyer | fwereade: That sounds like unnecessary mess in the system | 11:51 |
| niemeyer | Alternatively, we could disallow --force to be used without first calling without force | 11:51 |
| niemeyer | Which would set dying | 11:51 |
| niemeyer | THis would be a better teaching instrument than the grace period | 11:51 |
| rogpeppe | niemeyer: yes, that sounds better | 11:52 |
| fwereade | niemeyer, no remove-unit --force unless already dying SGTM | 11:52 |
| niemeyer | fwereade: Yeah | 11:52 |
| rogpeppe | niemeyer: then the user can choose their own grace | 11:52 |
| niemeyer | rogpeppe: Right, the issue becomes obvious | 11:52 |
| * fwereade is a little worried that the UA *will* be going around re-entering relations | 11:52 | |
| rogpeppe | fwereade: can it reenter a relation if the unit is dying? | 11:53 |
| fwereade | niemeyer, rogpeppe: and hence that --force might have to grind away at it a bit | 11:53 |
| * fwereade check | 11:53 | |
| niemeyer | fwereade: How can it re-enter a relation if it's dying? | 11:53 |
| niemeyer | Erm.. what Roger siad | 11:54 |
| niemeyer | said | 11:54 |
| fwereade | niemeyer, it shouldn't leave scope until it is completely done with the relation | 11:54 |
| rogpeppe | fwereade: "leave scope"? | 11:55 |
| niemeyer | fwereade: I still don't get it | 11:55 |
| niemeyer | fwereade: How can it *re-enter* while dying? | 11:55 |
| fwereade | niemeyer, because calling Join() when we're adding a relation we expect to do stuff with works right even if it's done twice | 11:56 |
| fwereade | niemeyer, let me double-check when we leave | 11:56 |
| niemeyer | fwereade: I still don't see the reason why it works while Dying there | 11:57 |
| fwereade | niemeyer, ok, do you agree that a unit should not leave a relation scope until it has run the relation-broken hook? | 11:57 |
| fwereade | niemeyer, (possibly when UA is down something else may leave scope for it, that is ont the question right now) | 11:58 |
| niemeyer | fwereade: Okay | 11:58 |
| niemeyer | fwereade: I still don't see the connection though | 11:58 |
| fwereade | niemeyer, the purpose of the scope doc is to indicate that a unit still needs the relation to be alive | 11:59 |
| niemeyer | fwereade: I understand that | 11:59 |
| fwereade | niemeyer, a Dying unit that has not run all its hooks needs that relation to be alive | 11:59 |
| niemeyer | fwereade: Yes, and how did we get to re-entering relation | 11:59 |
| niemeyer | s | 11:59 |
| fwereade | niemeyer, so when it comes up, it ensures that (if it knows itself to be part of the relation) its scope doc exists | 11:59 |
| niemeyer | fwereade: Yep | 12:00 |
| niemeyer | fwereade: So..? | 12:00 |
| fwereade | niemeyer, with the proposed style of remove-unit, we will be leaving its scope from outside, and it will be erroring out, coming back up, and rejoining scopes we've already exited | 12:00 |
| fwereade | niemeyer, the 5s break should be enough to make that only happen once | 12:00 |
| fwereade | niemeyer, maybe not at all | 12:00 |
| niemeyer | fwereade: Do we allow it to create scope documents even when it is dying? | 12:00 |
| niemeyer | fwereade: *create* scope documents | 12:01 |
| fwereade | niemeyer, there's no distinction at the API level -- EnterScope could be EnsureInScope | 12:01 |
| niemeyer | fwereade: Can you answer the question, for once? :-) | 12:02 |
| fwereade | niemeyer, yes, we allow it to create scope documents at any time we are certain that it is appropriate for it to have a state document, which includes when the unit is Dying | 12:02 |
| fwereade | s/state doc/scope doc/ | 12:02 |
| niemeyer | fwereade: Okay, i don't think we should allow it to create scope documents whne when it is dying | 12:03 |
| niemeyer | fwereade: It makes no sense to be establishing new participation in relations when the unit is dying | 12:03 |
| fwereade | niemeyer, I could just as easily say it makes no sense to be messing around with a unit's state while the unit is Dying and still responsible for its own state | 12:04 |
| niemeyer | fwereade: You could, but I don't get what you mean by that | 12:04 |
| niemeyer | fwereade: I'm pinpointing a very specific case which I was hoping would be easy to agree or disagree on itself | 12:04 |
| niemeyer | fwereade: If the unit is not in a scope, and is in a dying state, it doesn't make sense to be joining relation it wasn't in, AFAICS | 12:05 |
| fwereade | niemeyer, why are we even considering relations it's not already in? | 12:05 |
| niemeyer | * fwereade is a little worried that the UA *will* be going around re-entering relations | 12:06 |
| fwereade | niemeyer, "at any time we are certain that it is appropriate for it to have a scope document" means "when we know we're already part of the relation" | 12:06 |
| fwereade | niemeyer, if the unit agent is running and knows it should be in a relation it will call EnterScope | 12:06 |
| niemeyer | fwereade: There's someone else that disagreed meanwhile.. sounds like a straightforward race | 12:06 |
| niemeyer | fwereade: Yes, and then it's put to Dying, and that should fail | 12:07 |
| fwereade | niemeyer, well, yeah, I am a bit blindsided by all of this | 12:07 |
| fwereade | niemeyer, meh, no trouble, we can add that to the transaction | 12:07 |
| niemeyer | fwereade: Exactly | 12:07 |
| fwereade | niemeyer, induce a few errors while it's going down is not really a big deal I guess | 12:07 |
| niemeyer | fwereade: We don't have to induce errors.. EnterScope already does verifications of that nature | 12:08 |
| niemeyer | fwereade: Since we already disallow entereing a dying relation | 12:08 |
| niemeyer | fwereade: For similar reasons, I suspect | 12:08 |
| fwereade | niemeyer, we will absolutely be inducing errors by purposefully corrupting the uniter's state | 12:08 |
| niemeyer | fwereade: How's that "corrupting the uniter's state"? Putting a unit to dying is a normal condition | 12:09 |
| fwereade | niemeyer, looping through all its relations, leaving scope for each, while the uniter is valiantly trying to run its hooks *is* corrupting the uniter's state | 12:09 |
| niemeyer | fwereade: I'm talking about the case above still | 12:10 |
| fwereade | niemeyer, whether or not EnterScope should work when the unit is dying? I have no problem changing that, it's not a big deal, it will make no observable difference to the system AFAICT | 12:11 |
| niemeyer | <fwereade> niemeyer, meh, no trouble, we can add that to the transaction | 12:11 |
| niemeyer | <niemeyer> fwereade: Exactly | 12:11 |
| niemeyer | <fwereade> niemeyer, induce a few errors while it's going down is not really a big deal I guess | 12:11 |
| fwereade | niemeyer, sensible check, though, definitely a good thing | 12:11 |
| niemeyer | fwereade: That's the context in which you mentioned corrupting state and which I answered to | 12:11 |
| fwereade | niemeyer, ok, AIUI you are advocating roger's proposed style of remove-unit --force | 12:12 |
| fwereade | niemeyer, which is all about corrupting the unit's state as it runs | 12:12 |
| niemeyer | fwereade: I don't actually know. What was roger suggesting? | 12:12 |
| fwereade | niemeyer, EnsureDying(); leave scope for each relation unit; EnsureDead | 12:12 |
| niemeyer | fwereade: Is there an alternative you were suggesting? | 12:13 |
| fwereade | niemeyer, I had felt that the sane thing to do was to either have an EnsureDead transaction that cleans up the necessary state in one go | 12:13 |
| fwereade | niemeyer, well, not necessarily sane | 12:14 |
| fwereade | niemeyer, the alternatives I saw were: | 12:14 |
| fwereade | niemeyer, 1) a potentially large and unwieldy transaction | 12:14 |
| fwereade | niemeyer, 2) some complicated corrective agent | 12:15 |
| fwereade | niemeyer, and I was not very happy with either | 12:15 |
| niemeyer | fwereade: I think there's another alternative that might be easier to implement | 12:16 |
| fwereade | niemeyer, rogpeppe has suggested just taking joint responsibility while the UA is running, and trying to shut itself down cleanly, by shutting everything down for it -- surely inducing errors -- and then setting it to dead when that's done | 12:16 |
| fwereade | niemeyer, I honestly don't like that solution much either | 12:16 |
| niemeyer | fwereade: Having the deployer being responsible for double-checking that the unit resources have been cleared if death was forced | 12:17 |
| niemeyer | fwereade: After killing the software, before removing from state | 12:18 |
| fwereade | niemeyer, that STM like a special case of "complicated corrective agent" | 12:18 |
| fwereade | niemeyer, but worth exploring, cool | 12:18 |
| niemeyer | fwereade: That sounds like cleaning resources to me.. | 12:18 |
| niemeyer | fwereade: Can't get simpler than that | 12:18 |
| niemeyer | fwereade: We can't clear resources without clearing resources | 12:18 |
| fwereade | niemeyer, ok, this to me somewhat changes the balance of Dying/Dead | 12:19 |
| niemeyer | fwereade: How? It doesn't seem to change them at all to me | 12:19 |
| fwereade | niemeyer, but could probably work very nicely, once we have containerisation in place | 12:19 |
| niemeyer | fwereade: I don't think waiting is necessary | 12:19 |
| fwereade | niemeyer, I'm pretty sure we had agreed that eg a principal should not be able to become Dead while its subordinates were still around | 12:20 |
| fwereade | niemeyer, because otherwise the subordinate would be holding a reference to a dead object it was not responsible for destroying | 12:20 |
| fwereade | niemeyer, and that would be a Bad thing | 12:20 |
| niemeyer | fwereade: Hmm.. yeah.. so how does that change the picture? | 12:20 |
| fwereade | niemeyer, so setting something to Dead, and having its deployer clean up the its various other connections of the system, seems wrong to me | 12:21 |
| niemeyer | fwereade: Sorry for being slow, but I don't understand the underlying point being made | 12:22 |
| fwereade | niemeyer, I had been working from a picture in which Dead was as good as removed from the perspective of the single entity responsible for actual removal | 12:22 |
| niemeyer | fwereade: --force means the thing itself can't clean up its connection to the rest of the system | 12:22 |
| niemeyer | fwereade: Something has to do that | 12:22 |
| fwereade | niemeyer, ok, you are saying that the deployer can clean up a unit's relations after the relation is dead? or not at all? | 12:22 |
| niemeyer | fwereade: If you want to do that at the command line, you'll be "corrupting the state" | 12:22 |
| niemeyer | fwereade: The only thing that can be sure the thing is actually dead is its runner | 12:22 |
| fwereade | niemeyer, yes, it is something else's responsibility to do the cleaning up | 12:22 |
| niemeyer | fwereade: Which is the deployer | 12:22 |
| niemeyer | fwereade: So that's the place we can clean up without corrupting the state | 12:23 |
| niemeyer | fwereade: But you don't think that's right, because..? | 12:23 |
| fwereade | niemeyer, a dead unit that's still participating in relations *is* corrupt state IMO | 12:23 |
| niemeyer | fwereade: We can ask the deployer to force its death without putting its status to Dead | 12:24 |
| mramm | BTW, just sent an e-mail with updated meeting times -- and moved them to thursday for this week since I'm traveling tomorrow. | 12:25 |
| niemeyer | mramm: Cool, cheers | 12:25 |
| mgz | mramm: saw that. won't be there for thursday (as I'm travelling) but the rest of our lot should be. | 12:25 |
| mramm | mgz: no problem. We are bound to be missing one or two folks most weeks in december! | 12:26 |
| fwereade | niemeyer, ok, so: a flag on units, checked by their deployer, that when set (1) causes the uniter to treat its unit as Dead and (2) causes its deployer to clean up its state, setit to dead, and uninstall it? | 12:26 |
| mramm | mgz: probably more most weeks. | 12:26 |
| niemeyer | fwereade: The uniter doesn't have to change.. as far as it knows, it's already Dying, so it *should* be aborting its activities | 12:27 |
| fwereade | niemeyer, and so it will be | 12:27 |
| niemeyer | fwereade: The force flag action would happen purely on the deployer | 12:27 |
| fwereade | niemeyer, ok, isn't it better for the uniter to see that someone else has taken responsibility, and just stop doing things? | 12:28 |
| niemeyer | fwereade: It will stop doing things, because the deployer will shoot it in the head | 12:28 |
| niemeyer | fwereade: There's no point in sending him a postcard telling its being shot in the head :-) | 12:28 |
| niemeyer | (and by now I'm probably in a list of dangerous people somewhere) | 12:29 |
| fwereade | niemeyer, haha | 12:29 |
| fwereade | niemeyer, this somewhat complicates the UnitsWatcher | 12:30 |
| fwereade | niemeyer, or the clients I guess, I just need it to send all changes | 12:30 |
| niemeyer | fwereade: I don't think it should change | 12:30 |
| fwereade | niemeyer, ok, so the deployer needs to set up kill-switch watches on each of its units itself? | 12:30 |
| mramm | also, friendly reminder to folks: put your vacation on the Juju Calendar so we all know it. | 12:31 |
| niemeyer | fwereade: Although, don't we already monitor all changes | 12:31 |
| niemeyer | fwereade: On units | 12:31 |
| fwereade | niemeyer, no, that watcher filters it to just lifecycle changes | 12:32 |
| niemeyer | fwereade: What does that mean in practice? Life is a field in the unit | 12:32 |
| fwereade | niemeyer, yes, when it gets a unit change it discards it unless Life has changed | 12:33 |
| niemeyer | fwereade: Right | 12:33 |
| niemeyer | fwereade: That sounds like a life-related change, and is in the same place as the other settings | 12:33 |
| niemeyer | fwereade: We'd just be comparing Life+ForcedDeath or whatever, instead of Life | 12:34 |
| niemeyer | fwereade: (just a strawman for now) | 12:34 |
| fwereade | niemeyer, sure, it's just a change to the watcher and a change to the deployer to handle the new possibilities | 12:34 |
| niemeyer | fwereade: Right | 12:34 |
| fwereade | niemeyer, I'm not suggesting it's the end of the world :) | 12:34 |
| niemeyer | fwereade: Sure, I'm just testing waters by suggesting it's actually simple | 12:35 |
| niemeyer | fwereade: and looking at your face while doing that ;-) | 12:35 |
| fwereade | niemeyer, it's not wrong, but it's not quite conventional either | 12:35 |
| fwereade | niemeyer, eg, if we're doing that, we should be handling ports changes on the firewaller similarly | 12:36 |
| fwereade | niemeyer, ie the MUW should be filtering for Life and Ports changes, not just life | 12:36 |
| fwereade | niemeyer, hmm, that will save us a goroutine for every unit and probably save us a lot of complexity actually | 12:37 |
| niemeyer | fwereade: Uh.. that'd be a more controversial change | 12:37 |
| fwereade | niemeyer, ok, this is interesting to me: what's the distinction? | 12:38 |
| niemeyer | fwereade: Ports are not lifecycle related | 12:38 |
| niemeyer | fwereade: Then we're designing an API purely based on how we designed who's using it | 12:38 |
| niemeyer | fwereade: Which is not generally a good idea, as it means high-coupling, and changes on one side cascade on meaningless changes on the other | 12:39 |
| fwereade | niemeyer, ok, in that case all I'm really bothered about is the change to the lifecycle -- either by adding a flag, or by adding new states | 12:39 |
| fwereade | niemeyer, neither fills me with joy | 12:39 |
| niemeyer | fwereade: Sure, but I've suggested the new flag to accommodate your other points.. we can't preserve the unit as dying, and yet know to kill its activities from outside, without knowing we should | 12:40 |
| fwereade | niemeyer, I'm still not saying it's bad, just that I'm nervous about it :) | 12:42 |
| niemeyer | fwereade: and who kills the subordinates in such circumstance? | 12:42 |
| niemeyer | Must be the deployer as well, since the principal is out-of-action | 12:43 |
| fwereade | niemeyer, this is entertaining, because it's actually a different deployer in that case | 12:43 |
| fwereade | niemeyer, the principal had a deployer | 12:43 |
| niemeyer | fwereade: Well, not really | 12:43 |
| niemeyer | fwereade: Right | 12:44 |
| niemeyer | fwereade: Sorry, yes, a different deployer from the one that originally fired things | 12:44 |
| niemeyer | fwereade: Which brings back a point: the machiner is not necessarily exactly the same as a principaller (ugh) | 12:44 |
| fwereade | niemeyer, so, all these concerns were what was leading me towards the idea that composing a transaction that asserted and did the Right Thing all in one place might be viable | 12:45 |
| niemeyer | fwereade: I don't understand what that means.. transactions asserting things don't solve any of the previous points I think | 12:45 |
| fwereade | niemeyer, how many ops would you consider to be an unacceptably large transaction? | 12:45 |
| niemeyer | fwereade: You can assert whatever, and transact, whatever and it'd still be corrupting someone else's state (according to what you described as that meant) | 12:46 |
| fwereade | niemeyer, composing a transaction that sets all the right things to Dead, and leaves their relation scopes, etc etc, is not intrinsically unreasonable, is it? | 12:46 |
| fwereade | niemeyer, the uniter expects to become arbitrarily Dead at some point and stops calmly when it finds itself so to be | 12:46 |
| niemeyer | fwereade: Depends on what you consider unreasonable.. it seemed that you were unhappy about changing state underlying running software | 12:47 |
| niemeyer | fwereade: That's not solving anything about that | 12:47 |
| niemeyer | fwereade: It'll still catch all uniters off-guard | 12:47 |
| fwereade | niemeyer, the uniters will hiccup once at most, and then return some specific error | 12:47 |
| fwereade | niemeyer, but suddenly becoming Dead is not an unexpected occurrence | 12:48 |
| niemeyer | fwereade: Nothing is unexpected if we say we're fine with it :-) | 12:49 |
| fwereade | niemeyer, right, we agreed some time ago that the uniter needed to cope with becoming unexpectedly dead, and that its role at that point was done | 12:49 |
| niemeyer | fwereade: Moments ago it sounded like there was some unhappiness about the fact the uniter is doing activities such as joining relations and whatnot while someone else was changing the game underlying it | 12:49 |
| dimitern | is there a difference between foo := &SomeType{} and foo := new(SomeType) ? | 12:50 |
| niemeyer | dimitern: Now | 12:50 |
| niemeyer | dimitern: No | 12:50 |
| fwereade | niemeyer, ok, there is state created by the uniter, that it considers itself to own | 12:50 |
| dimitern | niemeyer: 10x | 12:50 |
| niemeyer | dimitern: We use the former | 12:50 |
| niemeyer | dimitern: Just out of convention | 12:50 |
| fwereade | niemeyer, and there is other state that it doesn't change; it just responds to changes in it | 12:50 |
| dimitern | niemeyer: ok | 12:50 |
| fwereade | niemeyer, ok, bah, this is not true of Dead because it *does* set its unit to Dead: but at that point it also stops watching it, or doing anything at all, so it feels kinda sensible | 12:51 |
| fwereade | niemeyer, I am opposed to changing the unit's relation state from <something that does not change under the feet of a live uniter> to <something that does> | 12:52 |
| niemeyer | fwereade: So the one-big-transaction idea doesn't solve it, right? | 12:53 |
| niemeyer | rogpeppe: ping | 12:53 |
| rogpeppe | niemeyer: pong | 12:53 |
| fwereade | niemeyer, in my mind it does, but you are correct to point out that it is a pretty fuzzy distinction, and I'm having trouble putting my finger on it | 12:54 |
| niemeyer | rogpeppe: Do you have a moment for a call at the top of the hour, with the cloud-green team, regarding some kind of interaction with the API? | 12:54 |
| fwereade | niemeyer, I shall meditate upon this over lunch | 12:54 |
| rogpeppe | niemeyer: yes | 12:54 |
| niemeyer | rogpeppe: Cool | 12:54 |
| niemeyer | rogpeppe: https://plus.google.com/hangouts/_/d94c1034338161320971329404422704b987f4f9 | 12:54 |
| niemeyer | rogpeppe: I'm not there yet | 12:54 |
| rogpeppe | niemeyer: fetching macbook | 12:54 |
| niemeyer | fwereade: Sounds good, let's come back to it after lunch then | 12:55 |
| fwereade | niemeyer, I just had a thought on subordinate names | 15:16 |
| fwereade | niemeyer, at the moment it seems we have no way to guarantee via txn that only one subordinate can be created per principal unit | 15:17 |
| fwereade | niemeyer, ie we can't assert that no document with the same service and principal exists, right? | 15:19 |
| fwereade | niemeyer, but we could name them, eg, logging/wordpress/0 | 15:19 |
| fwereade | niemeyer, which makes some sort of sense | 15:19 |
| niemeyer | fwereade: The two issues seem independent | 15:20 |
| fwereade | niemeyer, and doesn'timpact anything else, because the only thing we can do to a unit is remove it | 15:20 |
| TheMue | (late) lunchtime, biab | 15:20 |
| fwereade | niemeyer, and there's no clear way to remove a subordinate without removing the relation | 15:21 |
| niemeyer | fwereade: bzr remove/destroy-unit? | 15:21 |
| niemeyer | Erm | 15:21 |
| niemeyer | juju | 15:21 |
| fwereade | niemeyer, ok, sorry, how would you expect that to work? | 15:22 |
| niemeyer | fwereade: Ah, indeed.. | 15:22 |
| niemeyer | fwereade: But that sounds pretty independent from the original point | 15:22 |
| niemeyer | fwereade: We're again trying to solve three problems at once | 15:22 |
| fwereade | niemeyer, yeah, just a supporting detail | 15:22 |
| niemeyer | fwereade: A) How to name units | 15:23 |
| niemeyer | fwereade: B) How to remove subordinate units | 15:23 |
| niemeyer | fwereade: C) How to limit a single subordinate unit per service | 15:23 |
| niemeyer | Per principal, rather | 15:23 |
| fwereade | niemeyer, I don't think we need B at this point, but it may become relevant I suppose | 15:23 |
| niemeyer | fwereade: I don't think we need any of them right now | 15:24 |
| fwereade | niemeyer, so I'm saying: C is a problem, A may be a solution | 15:24 |
| niemeyer | fwereade: Why is C a problem? | 15:24 |
| fwereade | niemeyer, because I am terminally suspicious of things changing state I don't expect to change, and I want to write something that will react sanely if the subordinate that was trying to be added showed up from another source | 15:26 |
| niemeyer | fwereade: Sorry, I can't relate the answer to the question | 15:27 |
| fwereade | niemeyer, I can check that no subordinate exists before I attempt the creation transaction, but I cannot assert within the transaction that no duplicate subordinate exists, and this leaves a window in which bad things can happen | 15:28 |
| fwereade | niemeyer, what of the above statement seems lacking in appropriate sanity? | 15:28 |
| fwereade | niemeyer, ofc we do not need to actually change unit names to do this | 15:29 |
| fwereade | niemeyer, but I *think* we do need at least to change what we keep in the _id field | 15:30 |
| niemeyer | fwereade: That seems like a pretty radical change | 15:30 |
| fwereade | niemeyer, sure, so let's drop that bit | 15:30 |
| niemeyer | fwereade: Should we try to look at the problem first? | 15:30 |
| fwereade | niemeyer, yes | 15:31 |
| fwereade | niemeyer, do you have any thoughts on it? | 15:31 |
| niemeyer | fwereade: So the idea is we want a subordinate service and a principal service to spawn a single subordinate unit for each principal unit. Is that a good way to put it? | 15:32 |
| fwereade | niemeyer, that every principal unit creates its own subordinate, yes | 15:32 |
| niemeyer | fwereade: Hmm.. no, I didnt' say anything about who creates what yet | 15:32 |
| fwereade | niemeyer, er, ok, what did you mean by "spawn" then? | 15:33 |
| niemeyer | fwereade: I mean existance | 15:33 |
| fwereade | niemeyer, so did I... | 15:33 |
| niemeyer | fwereade: Stuff creating its own foo seems to indicate otherwise, but okay, I'll suppose we're in agreement | 15:34 |
| niemeyer | fwereade: So at which point the subordinate units do get created in the state? | 15:35 |
| fwereade | niemeyer, I think it happens when a principal unit in a locally scoped relation successfully enters the relation's scope, and has no subordinate | 15:36 |
| fwereade | niemeyer, and I'll just shut up now | 15:36 |
| fwereade | niemeyer, I can check the principal unit doc's Subordinates, and I can assert no changes to the principal unit doc, and retry as appropriate | 15:37 |
| niemeyer | fwereade: Hmmm, sounds sensible | 15:38 |
| niemeyer | fwereade: It'd be nice if we could even assert specifically that there are no subordinates of the given service there | 15:39 |
| niemeyer | fwereade: But I guess the language doesn't allow us to match on a prefix of a sub-entry, maybe | 15:39 |
| * niemeyer looks | 15:39 | |
| fwereade | niemeyer, hmm, I'd expect we could but I'm not sure offhand | 15:39 |
| niemeyer | fwereade: Hmm.. equality does unwind the array.. I wonder if regexes work the same way | 15:40 |
| * niemeyer tries it | 15:40 | |
| niemeyer | fwereade: Works! | 15:42 |
| niemeyer | fwereade: http://pastebin.ubuntu.com/1408009/ | 15:42 |
| fwereade | niemeyer, awesome | 15:43 |
| fwereade | niemeyer, right, well, I know what I'm doing re adding them, anyway :) | 15:43 |
| fwereade | niemeyer, I feel like I still need to think a bit about removal based on the discussion earlier | 15:44 |
| fwereade | niemeyer, I will try to grab you sometime later this evening if I can | 15:44 |
| fwereade | niemeyer, thanks :) | 15:44 |
| niemeyer | fwereade: Actually, I think that's more like what we want: http://pastebin.ubuntu.com/1408022/ | 15:44 |
| niemeyer | fwereade: As we can assert it | 15:45 |
| fwereade | niemeyer, yep, verytrue | 15:45 |
| fwereade | blast, need to pop to the shops, back imminently | 15:51 |
| === flaviamissi is now known as flaviamissi_ | ||
| niemeyer | fwereade_: Is there any follow up that justifies changing the type of relation ids to ints? | 17:43 |
| niemeyer | fwereade_: Or from ints, I guess | 17:43 |
| fwereade_ | niemeyer, not imminent, I'm afraid | 17:44 |
| fwereade_ | niemeyer, do you not feel the zero-value change is worth it? | 17:45 |
| niemeyer | fwereade_: If that's the motivation, just disallow 0? | 17:45 |
| niemeyer | fwereade_: I'm mainly trying to understand what's going on | 17:45 |
| niemeyer | fwereade_: It feels like we've been in a campaign against int keys, and I'm not sure why :) | 17:45 |
| fwereade_ | niemeyer, also, it feels more consistent to me -- but I agree that this proposal doesn't have the weight behind it that machine ids have | 17:45 |
| fwereade_ | niemeyer, it's fundamentally about making things that are similar look similar, because I believe that then the ways to use them better will be clearer | 17:47 |
| fwereade_ | niemeyer, but honestly, relation ids are mainly a problem for me because of id/_id | 17:47 |
| niemeyer | fwereade_: I don't know.. I've never designed any software on which we had a database we tried to make ints look like strings so that they were similar | 17:48 |
| fwereade_ | niemeyer, if we called it something other than Id, and disallowed 0, I'd probably be just as happy | 17:48 |
| Aram | consistent interfaces are a virtue, see OpenVMS vs. UNIX. | 17:50 |
| Aram | good night | 17:50 |
| niemeyer | Being a nice person too.. | 17:52 |
| fwereade_ | niemeyer, whatever we call it I don't think we index it yet anyway | 17:52 |
| niemeyer | But that's harder to get right.. | 17:52 |
| fwereade_ | niemeyer, I can understand him not wanting to get drawn into the argument :) | 17:54 |
| niemeyer | Sounding like an ass and then leaving is indeed a great way to make friends. | 17:55 |
| fwereade_ | niemeyer, anyway, the more I think about the relation IDs the less I care what type they are, so long as we clearly disambiguate them for Key/_id | 17:55 |
| fwereade_ | niemeyer, that#'t the core of my discombobulation here | 17:56 |
| niemeyer | fwereade_: If we were to unify things and interfaces, to be honest I'd try to do the opposite of what we've been doing.. I'd make everything have a surrogate key that is an integer | 18:08 |
| niemeyer | fwereade_: I appreciate the advantages of that novel idea that is binary numbers :) | 18:09 |
| niemeyer | fwereade_: 400kb holds 100 thousand ids, in a properly balanced and aligned tree. | 18:10 |
| fwereade_ | niemeyer, do you recall me suggesting this when I first introduced the unification idea? | 18:10 |
| niemeyer | fwereade_: Hmm.. not with any emphasis | 18:11 |
| fwereade_ | niemeyer, as it is, we have consistent string _ids throughout, and a surrogate integer key on relations | 18:11 |
| fwereade_ | niemeyer, which, it crosses my mind, we probably ought to index ;) | 18:11 |
| niemeyer | fwereade_: Yep | 18:11 |
| fwereade_ | niemeyer, so my own consistency hunger is actually largely assuaged -- I just don;t like the inconsistent and/or confusing terminology :) | 18:12 |
| fwereade_ | niemeyer, ie Name/Id/Key for various types | 18:13 |
| fwereade_ | niemeyer, and one with an extra Id that doesn't mean what the other id means | 18:13 |
| niemeyer | fwereade_: It was pretty consistent before | 18:13 |
| niemeyer | fwereade_: Id => int | 18:13 |
| niemeyer | fwereade_: Name => string | 18:13 |
| niemeyer | fwereade_: Now it's somewhat arbitrary or consistent, depending on how you slice it | 18:13 |
| fwereade_ | niemeyer, I guess we place different weights on different kinds on consistency | 18:15 |
| fwereade_ | niemeyer, although I note you don't mention Key in there | 18:15 |
| fwereade_ | niemeyer, or the fact that a casual observer might expect that an Id would be indexed | 18:15 |
| niemeyer | fwereade_: A non-casual observer (me) would expect it to be indexed as well | 18:16 |
| fwereade_ | niemeyer, so, well, there is at least agreement that we need to do that :) | 18:16 |
| niemeyer | fwereade_: To me having different types on primary keys is really not a big deal, if that's what you meant by the weights | 18:17 |
| niemeyer | fwereade_: Primary keys, at least where I've been lucky to observe, tend to reflect the application model | 18:18 |
| niemeyer | fwereade_: A person will generally have an id, or a username.. the id is generally an integer, not a string. | 18:19 |
| niemeyer | fwereade_: The username, if used, is a string | 18:19 |
| niemeyer | fwereade_: Etc | 18:19 |
| fwereade_ | niemeyer, are you arguing that I should reverse the machine ID change? | 18:22 |
| fwereade_ | niemeyer, because I am not actually arguing for a type change on relation id at the moment, just a name change | 18:22 |
| niemeyer | fwereade_: No, I'm having a pretty high-level conversation about what we're pursuing | 18:22 |
| niemeyer | fwereade_: Well, there's a branch to change it up for review.. that's as close to arguing about a change as it gets :-) | 18:23 |
| fwereade_ | niemeyer, ISTM that you are clearly going to reject this change, and I've been fighting a desparate rearguard attempt to get you to admit that, at least for morons like me, it *is* confusing to have a field called Key that serializes as _id and one call Id that serializes as id | 18:24 |
| fwereade_ | niemeyer, and that maybe we could change it, or you could explain how we benefit by this choice of names? | 18:25 |
| niemeyer | fwereade_: Right, that's where our conversation started.. | 18:26 |
| fwereade_ | niemeyer, ok, you just told me that I had been arguing about the type of the field | 18:26 |
| fwereade_ | niemeyer, I thought I had clearly conceded that point | 18:27 |
| niemeyer | fwereade_: You did, sorry | 18:27 |
| fwereade_ | niemeyer, I apologise if this was unclear | 18:27 |
| niemeyer | fwereade_: It wasn't | 18:27 |
| fwereade_ | niemeyer, ok -- so, I have no technical arguments for changing the type of relation.Id, but I would*really* like to change the field name | 18:28 |
| fwereade_ | niemeyer, the Tag suggestion I made in the CL is pretty clearly bad | 18:28 |
| niemeyer | fwereade_: Okay, what if we introduced surrogate keys for all types | 18:28 |
| fwereade_ | niemeyer, I would rather like that, I think, even if having separate getters might be slightly unattractive | 18:29 |
| niemeyer | fwereade_: Id/_id | 18:29 |
| niemeyer | fwereade_: ints | 18:29 |
| fwereade_ | niemeyer, I thought the _id field would not be suitable, because we don't get the uniqueness verification from name collisions? | 18:30 |
| fwereade_ | niemeyer, but I'd willing to skip that derail for now | 18:30 |
| niemeyer | fwereade_: We'll likely have to add some check on adds, yes | 18:31 |
| fwereade_ | niemeyer, Id/_id and Name/name, each of which must be unique, would feel to me like a good thing | 18:31 |
| niemeyer | fwereade_: Right, and Name present only where it makes sense | 18:31 |
| niemeyer | fwereade_: We can also rule out zeros | 18:32 |
| fwereade_ | niemeyer, are we thinking of a relation Key as a Name or not? :) | 18:32 |
| niemeyer | fwereade_: Yeah, I think that'd be fine | 18:32 |
| fwereade_ | niemeyer, ok, cool | 18:32 |
| niemeyer | fwereade_: It sounds good actually, rather than just fine | 18:33 |
| fwereade_ | niemeyer, so I *think* all the consequences here are good | 18:33 |
| niemeyer | fwereade_: I originally thought we could not remove the idea of machine zero, but I think any software that trusts it to be special is already broken since we don't offer this guarantee and will most certainly break it in the future | 18:33 |
| niemeyer | fwereade_: So we could start all valid counting from 1 | 18:34 |
| fwereade_ | niemeyer, I'm +1 on making it completely unspecial :) | 18:34 |
| niemeyer | fwereade_: Well, it is special, as it'd become invalid :-) | 18:34 |
| fwereade_ | niemeyer, I was sad to spot an explicit zero check in the code somewhere | 18:34 |
| fwereade_ | niemeyer, haha, reverse special :) | 18:34 |
| niemeyer | fwereade_: Yeah, we've always had it, but it's always been consciously a temporary hack | 18:35 |
| fwereade_ | niemeyer, ok, so a big Id/_id/int change would be for the better; I'm not sure how soon I can pick that up while still in the throes of subordinates | 18:36 |
| niemeyer | fwereade_: Understandable | 18:38 |
| fwereade_ | niemeyer, ...and cath has just made supper, so I should leave you for a bit | 18:38 |
| fwereade_ | niemeyer, I shall try to be on later, but no guarantees I'm afraid | 18:38 |
| niemeyer | fwereade_: np, thanks for the ideas | 18:38 |
| niemeyer | fwereade_: and have fun there | 18:38 |
| fwereade_ | niemeyer, cheers, enjoy your evening :) | 18:41 |
| niemeyer | fwereade_: Thanks | 18:43 |
| rogpeppe | i'm also off for the evening. | 18:44 |
| rogpeppe | night all | 18:44 |
| === flaviamissi_ is now known as flaviamissi | ||
| niemeyer | rogpeppe: Have a good one too | 19:09 |
| === flaviamissi is now known as flaviamissi_ | ||
| niemeyer | davecheney: Morning! | 22:09 |
| davecheney | niemeyer: howdy! | 22:09 |
| davecheney | niemeyer: thanks for your suggestion | 22:09 |
| davecheney | our replies crossed in the either | 22:09 |
| davecheney | i'll look at that test now | 22:10 |
| niemeyer | davecheney: np, not sure if there's something there, but I think there might be a path towards a test | 22:10 |
| davecheney | niemeyer: % time juju status -e ap-southeast-2 | 22:19 |
| davecheney | machines: | 22:19 |
| davecheney | "0": | 22:19 |
| davecheney | agent-version: 1.9.4 | 22:19 |
| davecheney | dns-name: ec2-54-252-2-107.ap-southeast-2.compute.amazonaws.com | 22:19 |
| davecheney | instance-id: i-ff7b0ac5 | 22:19 |
| davecheney | services: {} | 22:19 |
| davecheney | real 0m2.231s | 22:19 |
| davecheney | user 0m0.288s | 22:19 |
| davecheney | sys 0m0.024s | 22:19 |
| davecheney | 2 two seconds !! | 22:19 |
| niemeyer | davecheney: Woha! | 22:20 |
| niemeyer | davecheney: That's the fastest I've seen it run, ever! | 22:20 |
| davecheney | so many fewer round trips | 22:20 |
| niemeyer | Okidoki | 23:02 |
| niemeyer | I'm heading off for the day | 23:02 |
| niemeyer | davecheney: Have a good time there | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!