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