[07:06] soooo much better [07:07] http://paste.ubuntu.com/1433970/ [07:57] Morning [07:58] TheMue, heyhey [07:58] fwereade: Can't see you, you are not here. ;) [07:58] fwereade: Morning. :) [07:58] fwereade: Thought you're on vacation today? [07:59] TheMue, kinda sorta -- I need to do a half day today to catch up with monday when I took an uncheduled one [08:00] TheMue, I haven't quite decied whether I'm "really" working this morning yet though [08:00] ;) [08:00] fwereade: Hehe, here sometimes typical office jobs have more clear constraints. [08:17] TheMue, ok, just popping out, sent another comment on the FW [08:18] fwereade: Just seen it, thanks. Enjoy your day. === mthaddon` is now known as mthaddon [11:03] mgz: ping [11:03] dimitern: can you hear me? [11:03] wallyworld_: no [11:09] *lol* [11:09] dimitern: hey [11:10] mgz: mumble? [11:11] I'm on. [11:32] hello. [11:34] Aram: Hi [11:43] Mornings! [11:47] niemeyer: morning [11:51] niemeyer: Hiya [12:04] So, lunchtime. BIAB [12:35] morning everyone [13:07] TheMue: ping [13:08] niemeyer, in case TheMue's still at lunch, I was wondering a bit about EnsureSubordinate naming [13:08] fwereade: Heya [13:08] fwereade: Are you working or on holiday today? [13:08] niemeyer, catching up a half day I took off unscheduled on monday [13:08] fwereade: Just to see how much I can bother you ;_) [13:09] niemeyer, I am eminently botherable :) [13:09] ROTFL [13:09] fwereade: Cool, let's see naming first then :) [13:09] niemeyer, EnsureSubordinate is, in my mind, a sensible contraction of EnsureHasSubordinateIfThatIsSensible [13:10] fwereade: Agreed, not trying to explain it all there [13:11] niemeyer, for some reason EnsureHasSubordinate feels, er, a bit different [13:11] fwereade: The clarity I was aming for is that foo.EnsureBarer generally ensures that foo is a barer [13:11] fwereade: It feels awkward to call out ru.EnsureSubordinate() when ru must necessarily not be a subordinate [13:12] niemeyer, yeah, that makes sense -- I was also pondering EnsureSubordinateState at one point, but that didn't seem quite clear either [13:13] fwereade: To be honest, I think ru.CreateSubordinate would be best [13:13] fwereade: Returning ErrSubordinateExists or ErrSubordinateInvalid [13:13] niemeyer, I was just about to suggest those :) [13:14] fwereade: Hah, jinx then :) [13:14] niemeyer: Pong, just had to bring my daughter to her voluntary work. [13:14] niemeyer, that's great then -- grab me when you're done with TheMue then? [13:14] TheMue: Nice.. does she work voluntarily on the voluntary work? :-) [13:15] TheMue: I'll need some extra time to look over the logic on the branch actually [13:15] niemeyer, hah, when I was at school, there was an institution called "voluntary tea" on friday afternoons [13:15] niemeyer, no, it was not voluntary :/ [13:15] TheMue: I'm just going over the firewaller change [13:15] niemeyer: Hehe, yes, it's for bridging the time until her education as occupational therapist. [13:16] fwereade: Hehe, that's how it generally goes :-) [13:16] niemeyer: Ah, fine, has been a lot of discussion by fwereade and me in there. [13:17] * fwereade hopes he hasn't been leading TheMue up the garden path [13:31] niemeyer, a thought is squatting toadlike in my brain, and while I don't like it very much it will not leave peacefully [13:32] niemeyer, I don't think that CreateSubordinate actually deserves an independent existence -- it'd only ever be called just after EnterScope, and it depends on basically the same things... I can't think of a good reason not to roll CS into ES [13:32] fwereade: Sounds good as well. [13:34] niemeyer, ok, great, I'll have a go at that -- and that then means the errors collapse back down to ErrCannotEnterScope, I think [13:35] niemeyer, it will also demand a RelationUnit.Subordinate method, I think, but I don't need that quite yet (in fact I will only want it for testing) [13:35] niemeyer, anyway I will try it out and let you know how it goes [13:36] niemeyer, oh: crack check: I shouldn't bother to check related service life state because, if the relation is alive, both its services must also be alive [13:38] fwereade: Hmm.. good point [13:38] niemeyer, (and, yay, that is a statement of truth not just of intent) [13:38] niemeyer, cool, cheers [14:21] niemeyer, just in case, do you know if anyone knows what next spring's UDS dates will be? [14:21] fwereade: Not yet.. have you checked the UDS website? [14:22] niemeyer, all it seems to have is copenhagen [14:23] TheMue: Review sent [14:24] niemeyer: Great, thanks. [14:27] TheMue: np, please let me know if it makes sense [14:28] Heading to lunch now [14:29] niemeyer: Yes, first look is fine, just started to adopt it. For the approach we have to thank William and his steadiness. It has been a great help. [14:29] niemeyer: Enjoy your luch. [14:32] TheMue, a pleasure, thanks for your patience, I'm not sure I was always very clear :) [14:34] fwereade: It has been fine to tame this pretty nice beast, a good experience. [14:43] is there a neat way to run a single live test? I'm failing at finding the right go test spelling. [14:47] -gocheck.f [14:47] where regexp matches the test function name. [14:48] mgz: ^ ^ [14:49] ah, that was it, need to remember -gocheck not -test flags [14:49] thanks Aram [14:49] cheers. [14:54] okay, fixing this bug the way I would like will be annoying [14:55] ideally I'd write a way in the goamz fake server thing that reproduced this behaviour, so running the problematic live test failed in the correct manner, then fix the live test itself [14:56] but that's two different projects and custom behaviour for a specific test... [15:12] So, AFK again. [15:40] niemeyer, rolled subordinate creation into EnterScope in https://codereview.appspot.com/6906046/ [15:41] niemeyer, (I also addressed your comments in https://codereview.appspot.com/6845120/ -- I would love it if you had a moment to take a look before you depart...) [15:41] TheMue, a second look at https://codereview.appspot.com/6906046/ would be appreciated: it's changed pretty significantly since you saw it last [15:46] fwereade: Yo [15:47] fwereade: Will look at both [15:47] Now [15:48] fwereade: "This'd be Unit.EnsureDead's job, but it doesn't do it." [15:48] fwereade: Should we adapt comments in the respective places so they reflect what we want to happen then? [15:48] niemeyer, yeah, that's a good idea [15:49] niemeyer, I thought of that just after I submitted :/ [15:49] fwereade: Super [15:49] fwereade: "Nothing -- but it was a single-use method that I factored back into the single [15:49] caller... and then forgot to delete." [15:49] fwereade: So the method is now unused? [15:49] niemeyer, isn't it gone in that CL? [15:50] niemeyer, ah, yes, it is deleted now [15:50] niemeyer, yeah [15:51] fwereade: Cool, sounds good then [15:52] fwereade: I think there was some misunderstanding regarding the name [15:52] fwereade: I was suggesting isAliveDoc for the bson.D document [15:52] niemeyer, oh, sorry? [15:52] niemeyer, ha! [15:52] sorry [15:52] fwereade: np [15:54] fwereade: and isDeadDoc, respectively [15:54] niemeyer, notDeadDoc I presume [15:54] fwereade: Ugh, yes [15:54] niemeyer, sgtm [15:54] fwereade: Nice to see how much simpler the logic is since we don't have to consider errors [15:55] fwereade: I mean, we don't have to figure what happened to return the proper error [15:55] niemeyer, isn't it-- although EnterScope is some where near the edge my comfortable-complexity limit [15:55] fwereade: Indeed, it's probably the most complex function we have in state ATM [15:56] niemeyer, at least I can't think of any others that'll be that bad [15:57] fwereade: Agreed. And the logic is also readable, I think [15:57] fwereade: Perhaps requiring some context, though [15:57] niemeyer, ah, I tried to do that :( [15:58] fwereade: Should LeaveScope kill the subordinate unit? [15:58] niemeyer, nope, don't think so -- it has an independent existence and agent and its own shutdown sequence [15:59] niemeyer, setting the prinicpal to dying should do the same to its subordinates, and then we should just sit back and wait [15:59] fwereade: Hmm.. [15:59] fwereade: What kills the unit when the relation is departed then? [16:01] niemeyer, good point [16:01] niemeyer, I still don't think it's LeaveScope's job [16:02] niemeyer, I think if anything that a subordinate unit should also be watching for its relation's death [16:02] niemeyer, s/death/Dying/ [16:02] niemeyer, just as all units do with their services [16:02] fwereade: Sounds sensible, but isn't LeaveScope precisely the final cue that the relation is gone? [16:03] fwereade: Perhaps the action should take in the subordinate, though, rather than the principal [16:03] s/take/be taken/ [16:04] fwereade: Perhaps not.. if the relation is removed earlier the subordinate will never enter it [16:04] niemeyer, yeah, I'm still thinking it through [16:04] niemeyer, in general LeaveScope happens pretty late though [16:05] niemeyer, I think I'd like the subordinate agents to start clearing themselves up at the right point independently of what the principal does [16:05] fwereade: Sure, but let's think about a worse case scenario [16:05] fwereade: It's entirely possible that by the time the subordinate unit runs, the relation doesn't even exist anymore [16:05] s/worse/worst/ [16:06] fwereade: Right? [16:06] fwereade: +1 on your last comment [16:06] niemeyer, yeah, you're right [16:08] niemeyer, this is a dependency I had not hitherto considered :/ [16:09] fwereade: I think it's all good, though.. we just need specific logic in the subordinate unit agent that observes the right moment to suicide [16:10] niemeyer, yeah, indeed -- it's just that there's no very obvious way to be sure which relation the subordinate exists as a consequence of [16:11] niemeyer, I *think* the easiest way to handle that is to tag subordinate units with the relation ID they exist because of [16:11] niemeyer, but that has not been thought through with any rigour [16:11] fwereade: Every subordinate unit has a principal field [16:12] fwereade: Either there must be a relation with that unit, or its life is compromised [16:12] A container relation, specifically [16:12] niemeyer, true -- so we *can* figure out the two services involved, and thereby figure out the relation, maybe-probably, because I am suspicious of what happens if that relation is discarded and recreated [16:13] niemeyer, IMO an additional field meaning "this unit's life is also contingent on that of this relation" feels like a more certain way to do it [16:13] fwereade: That'd probably be a situation in which it'd be fine for the unit to stay around [16:14] fwereade: That'd open the potential for other races, though [16:14] fwereade: Such as having two subordinate units [16:14] niemeyer, *probably*, yeah, but it's the sort of chain of suppositions that I am suspicious of [16:14] fwereade: For the same service [16:14] niemeyer, I don't *think* that can happen [16:15] niemeyer, but I am not willing to swear that there will be no surprising consequences [16:15] niemeyer, I would prefer to keep the chains of logic as short as possible [16:16] fwereade: Sounds good, but I'm not sure of what you mean by that [16:17] niemeyer, principal -> principal's service -> figure out the relation [16:17] niemeyer, vs [16:17] niemeyer, relation [16:17] niemeyer, there are a lot more opportunities for bugs in the former [16:19] niemeyer, given two services we cannot necessarily uniquely determine the relation between them [16:19] niemeyer, but, ha, that's enough to sink my proposal [16:20] niemeyer, there's nothing stopping us having two distinct container relations between the same two services, is there? [16:20] niemeyer, not that that's a *nice* thing to do [16:20] fwereade: Nope [16:20] fwereade: I think it's a fine thing to do [16:21] fwereade: For the same reason that it's fine to have more than one relation between arbitrary services [16:21] niemeyer, indeed so [16:21] niemeyer, ok, maybe you're right [16:21] fwereade: Either way, I'm vaguely convinced that being able to ask whether two named units are part of a common relation must not be a hard question [16:22] niemeyer, if *any* Alive container relation exists between the subordinate's service and its principal, the subordinate should be Alive [16:22] fwereade: Given that a uniter already maintains tight control of remote participant units on any given relation [16:22] fwereade: That's right [16:22] niemeyer, I think that's a subtly different question [16:23] fwereade: Ah, you're right, yes [16:23] fwereade: It doesn't really matter whether the relation is established or not [16:23] fwereade: It matters if it exists [16:23] niemeyer, yeah, exactly [16:24] niemeyer, but, still, I think it's less hard than I feared two minutes ago [16:25] fwereade: Yeah, thinking in terms of a database query, it's "foo:.* bar:.*" || "bar:.* foo:.*" exist and is alive [16:25] niemeyer, (and, fwiw, this CL is very firmly focused on creation rather than removal -- subordinates we can't delete are suboptimal but (?) on par with python) [16:25] exists [16:25] niemeyer, yep, exactly [16:25] fwereade: I know.. it's approved already [16:25] niemeyer, ah, nice :) [16:25] * fwereade can be slow at times [16:25] fwereade: I just raised the issue as a brainstorm for future steps [16:25] niemeyer, yeah, much appreciated [16:27] niemeyer, but we're agreed that it's not LeaveScope then? (the only bug I am aware of in LeaveScope is that it doesn't delete services when it needs to) [16:31] fwereade: Yeah, agreed [16:32] niemeyer, perfect [16:51] fwereade: next one is good to go too [16:54] niemeyer, sweet :D [16:57] TheMue: https://codereview.appspot.com/6875053/ reviewed too [17:05] niemeyer, would you expand a little on "deploying agent" vs "deploying unit" -- my heart still favours the first [17:05] niemeyer, (I'm fine changing it, I'm just not sure why :)) [17:05] fwereade: DeployUnit does significantly more than deploying an agent [17:05] fwereade: An agent is jujud process running [17:05] fwereade: DeployUnit can do whatever it pleases to put the agent to run [17:06] niemeyer, bingo, thanks [17:06] fwereade: Including creating a container, downloading an image, running a container, etc [17:09] niemeyer: Thx for review. [17:19] niemeyer, ok, well, now that deployer's in, the how-to-merge-question comes up: I'm still not convincer that a MachinerWorker is a good reason to start a Deployer worker [17:19] niemeyer, it feels a bit off to me [17:19] fwereade: So let's do the change we discussed the other day and have flags there instead [17:19] niemeyer, task-per-flag? <3 [17:20] niemeyer, upgrader I presume remains implicit? [17:20] fwereade: Not task per flag.. flag per flag :).. the idea is precisely to avoid the 1-to-1 relationship between code and run mode [17:21] fwereade: Flags can possibly change the way that code run, instead of adding a new task [17:22] niemeyer, ah, ok, I wasn't really quite expecting you to have changed your mind there [17:22] fwereade: We had already gotten to that point in our last conversation IIRC [17:22] niemeyer, but the idea has not quite clicked with me, I'm afraid, and I'm a little nervous that I will do something completely unlike what you expect [17:23] niemeyer, yeah, but I did some independent thinking last weekend and accidentally dragged my comprehension of the problem back towards my initial viewpoint [17:23] fwereade: Okay, so how does it stand now? [17:25] niemeyer, basically I've confused myself -- I ran with an Agent idea for a bit and I think it's nice but I can't really justify it yet :( [17:26] niemeyer, or, at least, I don't have the time or emotional fortitude necessary to convince you before you go on holiday even if I am right ;p [17:26] fwereade: Hehe :) [17:26] niemeyer, and I am reluctant to sneak it past you while you're away [17:26] niemeyer, because I doubt you would appreciatethat too much ;)_ [17:26] fwereade: So let's try to reach some quick agreement.. feel free to sneak it in as we go [17:27] niemeyer, haha [17:27] fwereade: What we have now is a document in the database representing the machine [17:27] fwereade: That document has a field with a few names that we map 1-to-1 to what we call workers, which are really packages under the worker directory which tend to do relevant and mostly independent tasks within an agent [17:28] fwereade: agent being the name we give to a jujud process that we run to control stuff up in situations where one or more workers are necessary [17:28] fwereade: So far so good? [17:28] niemeyer, yep [17:29] fwereade: Cool.. so the discomfort we're sitting in happens because we rightfully renamed one of our workers to adapt the code [17:30] niemeyer, indeed [17:30] fwereade: and the fact we have fields which are tied to code name rather than the intended semantics for the running logic means we're forced to swallow a mismatch, or fix it, or change the way we refer to that kind of semantics so that we avoid future mismatches [17:30] fwereade: I'm suggesting the latter [17:30] fwereade: and part of my motivation is that I think the 1-to-1 mapping between package name and semantics is too artificial to survive over time [17:31] niemeyer, ok -- I guess my own discomfort here is that I'm not clear on what the intended semantics are [17:31] fwereade: Understood. That's easy to solve, I think. [17:31] niemeyer, you have stated the problem helpfully though [17:31] * fwereade is all ears [17:31] fwereade: We have three different flags today: [17:32] fwereade: Flag 1) "I want this agent to manage the firewall for the environment" [17:32] fwereade: Flag 2) "I want this agent to manage the provisioning of machines for the environment" [17:32] fwereade: Flag 2) "I want this agent to manage the hosting of units for that machine" [17:32] s/2/3/ on the last, of course [17:33] niemeyer, right, yes, agreed [17:33] * niemeyer holds off a bit [17:34] fwereade: Welcome back [17:35] fwereade: So [17:35] grar, sorry [17:35] LOL [17:35] sorry, that time the actual client crashed :/ [17:36] fwereade: No worries [17:36] fwereade: So! [17:36] :) [17:36] fwereade: We have these three stated semantics [17:36] * fwereade sits very still [17:36] fwereade: My proposal was to find a way to name the intended semantics without actually referring to worker, or task [17:37] fwereade: But rather as a property of the machine itself [17:37] fwereade: and at the agent side, we map these flags to workers, tasks, or whatever we please [17:38] niemeyer, ok, that SGTM -- and that reduces the current problem to a naming question really, just a different one to that I had previously imagined [17:40] fwereade: Cool.. so how do we name those flags? Hmmm [17:41] * fwereade is still a touch baffled by this question [17:41] fwereade: Hm? [17:42] fwereade: I'm baffled by your baffledness :-D [17:42] niemeyer, I don't know what we should name them [17:43] niemeyer, well, Firewaller and Provisioner are a bit too close to the worker names for comfort -- the implication is that flags *do* map onto workers [17:43] niemeyer, and I really don't like "machiner" [17:44] fwereade: Strawman: HostProvisioner, HostFirewaller, HostUnits [17:45] niemeyer, ok, I think I can work with those :) [17:45] fwereade: Although HostFirewaller is still not great [17:45] fwereade: Because we'll likely have local firewall management soonish [17:45] niemeyer, I think the big issue there is ... exactly [17:46] niemeyer, I'm almost tempted to roll firewalling into provisioning again [17:46] fwereade: ManageEnvironFirewall, ManageEnvironProvisioning, HostUnits [17:46] niemeyer, ie if HostProvisioner, we run both P and FW workers [17:47] fwereade: Hmm [17:47] fwereade: Interesting [17:47] niemeyer, or HostEnvironStuff ;p [17:47] niemeyer, (bad name, just saying I'm not attached ot the specific chars that make it up) [17:48] fwereade: Sounds like a good idea.. there's no great reason to separate those [17:49] niemeyer, ok, fantastic -- that feels like enough to be going on with [17:50] niemeyer, I am being encouraged to be a monster, and I think I should be off [17:50] niemeyer, have a very happy christmas with much joy and adequate sleep -- see you in the new year, I expect :) [17:50] fwereade: UnitsMachine and ControlMachine? [17:51] niemeyer, ...ambivalent, I will take those under consideration :) [17:51] fwereade: With int flags, so we can tweak names over time as we see fit [17:51] fwereade: Thanks a lot man :-) [17:51] niemeyer, ok, sounds sensible [17:51] fwereade: Have a great break as wel [17:51] l [17:51] niemeyer, always a pleasure, take care :) [17:52] fwereade: Tell Laura there's a little friend coming [17:52] fwereade: ;_) [17:52] niemeyer, will do :) [17:52] fwereade: I'll just have to make an effort for them to be able to communicate :_0 [17:52] :-) === TheMue_ is now known as TheMue