[06:41] fwereade: hiya [06:41] wrtp, heyhey [06:42] wrtp, actually, can I get your opinion on a naming issue in uniter? [06:42] fwereade: sure [06:42] wrtp, ok, this is about persistent states [06:42] wrtp, ATM I have Op (Install, Upgrade, RunHook, Abide) and Status (Queued, Pending, Committing) [06:43] wrtp, niemeyer suggests s/Status/OpStep/ (+!) and s/Committing/Done/ (not sure) [06:44] wrtp, I was wondering if a smarter naming scheme might burst fully-formed from your mind, because I think there's something wrong even with the changes that I can't put my finger on [06:44] fwereade: OpStep certainly seems a little odd [06:45] wrtp, well, Step perhaps -- I think it does beat Status -- but I think that maybe there's something larger that's wrong [06:45] fwereade: was this from comments in a review? [06:45] wrtp, yeah -- and its current form is at least partly a mix of what I originally thought and niemeyer's suggestions as well [06:46] wrtp, honestly I can live with it, with niemeyer's suggestions, and be perfectly happy [06:46] fwereade: can you link to his comment where he suggests OpStep? [06:46] wrtp, I'm just checking for a fresh perspective on it, because I think I had already overthought it a while ago [06:46] wrtp, just a mo [06:47] wrtp, https://codereview.appspot.com/6489083/diff/3001/worker/uniter/state.go#newcode31 and a comment just below as well [06:48] fwereade: i think he's suggesting s/Status/Op/ and s/Op/OpStep/ [06:49] fwereade: which makes more sense [06:49] wrtp, sorry, that makes no sense to me :( [06:49] fwereade: although i'm still not entirely sure [06:50] ISTM he's clearly referencing Status when he suggests OpStep... [06:51] and an Op does indeed pass through a number of steps/statuses/whatevers [06:51] fwereade: how about Op and OpStatus ? [06:51] wrtp, I *think* step is a win over status [06:52] fwereade: i'm suggesting that you just do s/Status/OpStatus/ [06:52] fwereade: because, if gustavo's right in that comment, the Status is the status *of* the op [06:53] ffs, sorry [06:54] last seen: [07:51:58] wrtp, I *think* step is a win over status [06:54] wrtp, ...the Status is the status *of* the op [06:54] fwereade: that's the last thing i said [06:54] wrtp, IMO step has a valid and helpful semantic payload over status [06:54] fwereade: i'm not suggesting we use step [06:55] fwereade: oh misread sorry [06:55] fwereade: i'm not suggesting we use step *instead of* status [06:55] wrtp, I know; but I think niemeyer is, and I think step is strictly etter than status [06:56] wrtp, what I'm whining about is a sense that it's still not *good* [06:56] wrtp, and I feel that I should probably recast the naming of all related states such that everything magically makes perfect sense [06:56] fwereade: it doesn't seem quite right to me, but i haven't looked at the code much. how is "queued" a "step"? [06:56] wrtp, but I can't figure out a better way of looking at them [06:57] wrtp, hm, yeah, ISWYM -- but they're steps in that they have a defined order to them [06:58] wrtp, an evil little part of me is suggesting Before/During/After might be a fruitful area for exploration [06:58] wrtp, anyway, don't let this seriously distract you [06:59] wrtp, I'm ok going with niemeyer's suggestions, but I'm hoping that a nice name-fixing followup will someday come to fruition [06:59] fwereade: i prefer OpStatus to OpStep - a step to me indicates an action not a condition [06:59] fwereade: as in "a step towards a better reality" :-) [06:59] wrtp, I see OpStep as specializing the Op action [07:00] wrtp, yeah, understood, might become convinced once it's percolated [07:00] fwereade: i see what you mean, but i think i see OpStatus as *about* the Op action [07:01] fwereade: and makes it clearer, perhaps, that an Op is something you *do* and an OpStatus is something you *move towards* [07:06] wrtp, is it though? I suspect you have an interesting view on this but I'm having difficulty meshing it with my own [07:08] wrtp, feels to me like an OpStep is something that you are *doing* (but, yeah, Queued doesn't fit there) [07:08] wrtp, steps: prepare, run, cleanup? [07:08] wrtp, not quite right either though :( [07:09] fwereade: what do you find not-quite-right about OpStatus? [07:10] wrtp, I find the whole naming scheme ...somewhat off [07:10] wrtp, that's as well as I can characterise it atm [07:11] fwereade: you're certainly coming from a deeper understanding of the problem than me [07:21] wrtp, heh, I think I'm way off in the Slough of Overthinking [07:21] fwereade: i know what you mean [07:22] fwereade: i'm just trying to convince myself of whether gustavo's right and my charm suite branch is in fact crack [07:23] fwereade: i'm just trying to convince myself of whether gustavo's right and my charm suite branch is in fact crack [07:24] wrtp, I *think* you're on the side of the angels there, but I'm not 100% sure [07:25] fwereade: it definitely *felt* good. the main part of his argument comes down to performance, i think, so i'm just checking if it has any measurable impact [07:25] wrtp, oh *crap* I've got to go out, completely forgot [07:25] wrtp, might be a couple of hours :( [07:25] and am late already, balls [07:25] fwereade: ok, see you later. have as much fun as you can doing what you're doing :-) [08:53] morning. [10:22] Aram: morning [10:25] fwereade: i'm just about to add upgrading to the uniter - just checking that you're not already working on it. [11:31] fwereade: can you help me to interpret gustavo's last remark here? https://codereview.appspot.com/6501106/diff/1001/worker/machiner/machiner.go#newcode28 [11:31] fwereade: i'm not sure i can understand it enough to do something right [11:47] wrtp, heyhey [11:47] fwereade: i *think* i've worked it out [11:47] wrtp, sorry about that, that was quite the unexpectedly complicated morning [11:47] fwereade: np [11:48] fwereade: i think that a container API like this might work: http://paste.ubuntu.com/1200404/ [11:48] wrtp, ISWYM, it's not entirely clear t what extent he's agreeing with me and to what extent he's saying something else [11:48] fwereade: wdyt? [11:49] * fwereade is thinking [11:49] wrtp, I think that, yes, *probably* we will want it to look like that [11:50] fwereade: i've got to do something like that, as i need to pass in the VarDir somehow [11:50] wrtp, the trouble is I kinda feel the surroundings are still somewhat in flux so I'm still not quite sure [11:50] wrtp, indeed [11:50] wrtp, I'd like it if we did the same with LogDir too [11:50] fwereade: i tried a more minimal change before, but perhaps this will be better looked on [11:50] fwereade: LogDir? [11:51] fwereade: you mean we should have container.Config.LogDir? [11:51] wrtp, /var/log/juju, needed for --log-file in jujud upstart scripts [11:51] wrtp, I *think* so, yes [11:51] fwereade: can't we just derive it from VarDir ? [11:52] wrtp, vardir/../../log/juju? [11:52] fwereade: oh yeah [11:52] :-) [11:52] ;p [11:52] fwereade: you're probably right. [11:52] fwereade: i'll add a TODO [11:53] wrtp, cheers [11:53] fwereade: is the log directory currently configurable anywhere in fact? [11:54] wrtp, I think it's just hardcoded in cloudinit [11:54] fwereade: i thought so. i don't mind that too much tbh, but some day [13:54] fwereade: any chance you could have another quick once-over on https://codereview.appspot.com/6501106 ? [13:54] fwereade: i made that container change; i'm hoping it's not yet more crack. [13:55] wrtp, ofc [13:55] wrtp, it's tricky -- I *know* there's something nice waiting to emerge from the marble somewhere around there but I don't think either of us have quite nailed it yet (although I think you are looking in the right place) [13:56] fwereade: it doesn't fix all the container problems (i have another branch for that), but i feel the API entry points are about right now. [14:05] wrtp, +1 on Deploy/Destroy [14:05] fwereade: thanks [14:05] wrtp, just rereading everything else to try to remember what was involved [14:05] niemeyer, heyhey [14:05] niemeyer: hiya [14:05] GOod mornings [14:05] Or afternoons I guess [14:08] niemeyer, sorry I missed you last night -- I'm still a little bit unsure about the uniter op/step naming, but have resolved to stop vacillating and propose it again more-or-less as you suggest; if I come up with something better that can be a new CL later [14:09] fwereade: Cool, I'm not super attached to those names either.. they just felt closer to what was going on than the State.Status stuff [14:10] niemeyer, yeah, I have a deep-seated feeling that there's some simple recasting of everything going on there that will make clear and obvious sense [14:10] niemeyer, the actual *logic* is really pretty trivial [14:10] niemeyer: i'm hoping that this isn't still crack: https://codereview.appspot.com/6501106 [14:11] niemeyer: and it would be nice if you could resolve the juju-dir/var-dir question with fwereade. i don't feel strongly either way. [14:11] niemeyer, well, I don't like VarDir unless it actually refers to /var, but I can live with any name really [14:12] if i had to choose, "jujuDir" feels more descriptive. varDir doesn't really mean anything other than "directory with some variable contents" to me [14:13] jujuRoot might work too [14:13] """ [14:13] It is vague because it is truly vague. The only thing it means is "juju's [14:13] directory under var", because under it we have a bunch of different things with [14:13] more precise naming (bundles, unit containers, etc). No single precise FooDir [14:13] name will encompass it all. [14:13] """ [14:13] niemeyer, well, it's *one* of juju's directories under var [14:14] niemeyer, if it were the only separate juju-specific dir under var I wouldn't be bothered [14:14] niemeyer: i'm not sure it's entirely relevant that it's under var. it *may* be under var, but that's a platform-specific decision. [14:14] niemeyer: hence we can configure it [14:14] wrtp, fwereade: Okay, alternatives? [14:14] niemeyer: jujuRoot ? [14:15] wrtp: That's / [14:15] niemeyer, we also used jujuHome in a couple of places in python iirc, but then that's not necessarily /var/lib/juju either [14:15] wrtp: Since that's the only directory that shares ~/.juju, /var/log/juju, /var/lib/juju, and whatever else we need [14:15] niemeyer, no favour for LibDir/LogDir? [14:16] jujuDataDir ? [14:16] or just dataDir, perhaps [14:16] DataDir? [14:16] niemeyer, +1 [14:16] wrtp: +1 :-) [14:16] :-) [14:16] ok, i'll go for that then [14:16] Woohay consensus [14:17] niemeyer: shall i change the flag name too? [14:17] perhaps i should do that in another CL actually [14:17] rather than bulking this one up more [14:20] wrtp: --data-dir sounds sane [14:23] * Aram food [15:03] fwereade: container fixed, i hope: https://codereview.appspot.com/6498117 [15:04] wrtp, sweet,k looking [15:13] wrtp, LGTM [15:14] wrtp, very nice [15:14] fwereade: wonderful thanks [15:24] fwereade, niemeyer: i've made the change to dataDir from varDir. https://codereview.appspot.com/6501106 [15:28] wrtp: Checking [15:31] wrtp, LGTM [15:31] fwereade: thanks [15:41] wrtp: done [15:43] niemeyer: what's the difference between container.Simple(VarDir, InitDir) and container.Simple{VarDir: varDir, InitDir: initDir} ? [15:43] niemeyer: given that we're eschewing globals, i can't see what the former can do that the latter can't [15:44] wrtp: This question seems to assume that we have Simple{}, which we don't.. so I don't understand why you're asking me that [15:44] niemeyer: we *did* have Simple, but you told me it was wrong. [15:44] niemeyer: so i changed to use the current scheme (which BTW i think is significantly better) [15:45] wrtp: Sorry, I'm pretty lost [15:45] wrtp: The branch is doing something else entirely [15:45] wrtp: I've reviewed it, and pointed it has issues [15:45] wrtp: Now you're blaming me for saying something else was improper, that is not what is in the branch, nor what I'm suggesting [15:45] wrtp: I'd like to help, but I don't know hwo [15:45] how [15:46] niemeyer: *somehow* i've got to pass VarDir and InitDir through to container. i changed container so that that was done in a nice way, i thought. [15:46] wrtp: Yes, that's exactly what my comment is about [15:46] wrtp: The package interface was changed entirely [15:46] wrtp: unnecessarily [15:46] wrtp: and I'm explaining that.. that's all [15:47] wrtp: The original interface was better, as it allows containers to be implemented without changing the consumer interface [15:47] niemeyer: i'm not sure i understand that [15:47] wrtp: It doesn't matter much, really [15:47] wrtp: your branch is about changing a global to a local.. we don't need to change the package interface for that [15:47] wrtp: We only need to provide simple with the location [15:48] niemeyer: i don't see why a function constructor is better than a data constructor in this case. [15:48] wrtp: The original interface was put in place precisely so that we can have multiple containers, with different needs, and the same interface [15:48] wrtp: We're losing that [15:48] wrtp: Let's not, please, and let's focus on what you're claiming to do with the bracnh [15:48] niemeyer: k [15:49] * wrtp rewinds the dataDir changes [15:49] wrtp: The data constructor is fine, btw [15:49] wrtp: If you want Simple{}, that's fine [15:49] wrtp: I don't think I argued against that [15:49] niemeyer: that's what i had that you objected to! [15:50] wrtp: Where did I do this? [15:50] "" [15:50] This is true, but the decision is made considering settings, which means [15:50] that the API won't look like this (won't receive it through [15:50] constructor), so I agree with William that this seems premature. It's [15:50] also a bit unrelated to the CL topic. [15:50] "" [15:51] wrtp: That's *completely* unrelated to the container package interface [15:51] wrtp: That's in *machiner* [15:51] wrtp: and is still true.. we don't have to pass a container through its constructor [15:51] niemeyer: ok, so why was that code wrong? i must have got the wrong end of the stick [15:51] (i did find that sentence difficult to parse, it's true) [15:51] wrtp: The machiner will never make good use of a container being passed through its constructor [15:52] wrtp: Because it needs to decide internally how it's supposed to deploy [15:52] niemeyer: there's only one Simple container though. [15:52] wrtp: !? [15:52] wrtp: and the sky is blue..? :) [15:53] niemeyer: there's only one Simple container that the machiner needs to use [15:53] niemeyer: it can use that for all local deployments [15:54] niemeyer: hence it can live in the Machiner struct AFAICS with no loss of generality [15:54] wrtp: Sorry, I don't understand your point.. yes, there's only ever going to be one Simple container in juju [15:54] wrtp: What does that mean? [15:54] niemeyer: it means i can store it in the Machiner struct, no? [15:54] niemeyer: which is what i was doing. i seem to be missing some fundamental issue here... [15:55] wrtp: You can store it wherever you want.. [15:55] wrtp: NewMachiner should not take a container [15:55] niemeyer: it doesn't [15:55] wrtp: That's William's point, and that's my point [15:55] niemeyer: it never did [15:55] niemeyer: the *internal* constructor took a container [15:55] niemeyer: so that we can see when deploys happen [15:56] niemeyer: (there's otherwise no way of finding that out, i think) [15:56] https://codereview.appspot.com/6501106/diff/1001/worker/machiner/export_test.go?column_width=90 [15:56] wrtp: That's broken [15:57] niemeyer: ok, so how can i test that the machiner is actually doing something? [15:57] wrtp: Sorry, can we stop the derail? [15:57] wrtp: This CL is changing VarDir to a local.. [15:57] wrtp: Can we do just that and move on? [15:57] wrtp: We've been debating about changes in interfaces to various things so far [15:59] niemeyer: the old code changed the instance of Simple in the container package, so it could mock it. [15:59] niemeyer: we can't do that any more. [15:59] niemeyer: so this was my simplest idea for changing that [15:59] wrtp: I don't understand.. we had a simple container being used [15:59] wrtp: simple := container.Simple{DataDir: dataDir} [15:59] wrtp: Done? [15:59] wrtp: I don't understand where all the debate is coming from [16:00] niemeyer: if we do that, how can the testing code know when the machiner is actually doing a deploy? [16:00] wrtp: How did we do that before? [16:01] niemeyer: Simple was a global variable of type container.Container. we changed its value in the test to our own local implementation. [16:01] wrtp: Argh, ok.. so we were already mocking before :( [16:01] niemeyer: yes. and given that container can't work if you're not root, i don't see how we can avoid it [16:02] wrtp: What's the simple container doing? [16:02] * niemeyer looks [16:02] niemeyer: it calls upstart.Install [16:02] wrtp: Yeah, so why is that being mocked? If we're passing the directories being changed in.. ? [16:03] wrtp: Hmm.. I suppose container is broken, since it should be starting the upstart script too? [16:03] niemeyer: sorry, i don't understand the second part of your question [16:03] wrtp: DataDir and InitDir are both variables [16:03] niemeyer: it does start the upstart script too, i think [16:03] wrtp: That we're now giving the machiner [16:03] wrtp: It should.. but it's not clear if it does.. [16:03] niemeyer: only DataDir actually [16:03] * niemeyer looks at what Install does [16:04] a installs and *starts*, ok [16:04] wrtp: Okay, sorry, the confusion is my fault then [16:05] wrtp: We are already stuck with the mocking of container, and once we introduce a second one we'll need to change the way we're testing the machiner [16:05] wrtp: +1 on your original design of passing a container in for tests [16:05] niemeyer: i think the container package can decide which container is appropriate to use, based on the Unit [16:06] wrtp: It wasn't clear to me that were were replacing what the container.Simpler global meant [16:06] niemeyer: that's the rationale for the most recent change [16:06] wrtp: It can't [16:06] niemeyer: no? ok. [16:06] wrtp: Container kind is an environment-defined setting, not per unit [16:07] niemeyer: what info does the uniter have that container doesn't? [16:07] niemeyer: and why couldn't that environment setting live in the Config? [16:07] wrtp: Sorry, I don't understand the question... container is a deployment package.. uniter has a lot of information that container doesn't [16:10] niemeyer: ok, so do i take it that my original code was ok? [16:11] wrtp: The original way in which you were testing machiner was ok, if that's your question [16:11] wrtp: We'll need to rethink it when we introduce LXC, but it doesn't matter for now [16:11] wrtp: We already have that problem [16:12] niemeyer: i think the most recent approach doesn't have the problems with LXC. the kind of container to use for isolation could be a parameter in the config. [16:12] niemeyer: and the container package could decide whether it's appropriate to isolate a unit [16:13] niemeyer: so the current machiner code would hardly need to change at all for LXC [16:13] niemeyer: i'm still pushing slightly for it because it's going to be a right hassle to rewind and go through another half-hour's worth of conflict resolution. [16:15] wrtp: If that's all it takes, we can trivially pass a set of containers instead of a single one and get to the same place.. [16:16] wrtp: The changes in design to the container package are not an improvement, and I'd appreciate if we didn't do that [16:17] wrtp: You're basically dropping the concept of a Container interface, and putting it all inside the package itself as hidden details, with a single jumbo config that acts for all containers [16:17] wrtp: It also takes away the ability for a container implementation to cache information, such as what are the things it has seen alive or not [16:18] wrtp: we'll have to land that information in globals instead, if we want to do it [16:18] wrtp: These aren't improvements [16:19] niemeyer: ok, i finally think i see where you're coming from on this. [16:20] niemeyer: thanks for explaining [16:21] wrtp: np, and sorry for the partial detail on the test of machiner.. I misunderstood there [16:21] s/detail/derail/ [16:21] niemeyer: that's ok. [16:21] niemeyer: luckily i can work late tonight [16:23] wrtp: Ouch [16:29] niemeyer: it's true that i'm a bit sad about the derail, but i'm also stoked to get past these branches and actually get stuff working. we're really very close. [16:33] wrtp: +1! [16:46] niemeyer: hopefully this will do the trick: https://codereview.appspot.com/6501106 [16:51] wrtp: Done, cheers [16:52] niemeyer: thanks [17:25] niemeyer: do you know about this test failure? http://paste.ubuntu.com/1200932/ [17:26] wrtp: ... Panic: no reachable servers (PC=0x4116D4) [17:26] wrtp: This is the root [17:27] wrtp: mgo.Dial is not finding the mongodb server running [17:27] niemeyer: is that a race thing? i only get this error sporadically [17:27] niemeyer: perhaps some timeout should be longer? [17:27] wrtp: 15 seconds is the default IIRC.. I've never seen a mongodb server take that long to start [17:27] niemeyer: (speaking of which, i got an mstate/presence failure this morning - the test that waits for 1 second) [17:28] wrtp: It's generally sub-second [17:28] niemeyer: i guess mongo just failed to start then [17:29] wrtp: Yeah, wonder why [17:29] niemeyer: is there a log somewhere? [17:29] wrtp: the suite will tell [17:30] wrtp: Apparently not [17:31] niemeyer: yeah, looks like s.output is dropped on panic. [17:31] niemeyer: that might be a useful thing not to do :-) [17:32] wrtp: Indeed [17:41] interesting. first time i've seen this live failure: [17:41] 07.05.602 /home/rog/src/go-alt/src/launchpad.net/juju-core/environs/jujutest/livetests.go:162: [17:41] 07.05.606 c.Assert(err, IsNil) [17:41] 07.05.606 ... value *errors.errorString = &errors.errorString{s:"session error: ZooKeeper connecting"} ("session error: ZooKeeper connecting") [17:41] niemeyer: i thought zk didn't time out. [17:45] wrtp: ... don't know what to say [17:45] niemeyer: 's'alright. i wondered if you might have seen similar. [17:45] wrtp: I haven't [17:45] niemeyer: it's not the world's most informative error message :-) [17:46] niemeyer: currently trying to reproduce. we'll see. [17:49] wrtp: zk definitely has timeouts, and we definitely fail if we get an error from zk [17:50] niemeyer: looks like it was a sporadic failure. [17:56] wrtp, fwereade: You'll probably like that one: https://codereview.appspot.com/6503109 [17:59] niemeyer: yay! LGTM [18:02] niemeyer: hmm, i did a apt-get update; apt-get install lbox and it hasn't found a newer version. should i use the Go version? [18:03] wrtp: There's certainly a new version in the PPA [18:03] wrtp: 1.0-56.64.39.11~precise1 [18:03] wrtp: This is the latest [18:04] * wrtp can't remember how to find the currently installed version [18:05] niemeyer: 1.0-47.61.38.10~oneiric1 [18:05] is what i've got [18:06] hmm, i wonder why i'm on an oneiric version [18:09] darn [18:09] % go get launchpad.net/lbox [18:10] package launchpad.net/lbox [18:10] imports exp/html: unrecognized import path "exp/html" [18:10] oh well, will wait until it works. can't be bothered to update to go tip for now. [18:14] niemeyer: could we have a chat about this? i'd like to move forward with it if possible. https://codereview.appspot.com/6495086/ [18:23] wrtp: [18:23] [niemeyer@gopher ..nchpad.net/lbox]% grep html * [18:23] [niemeyer@gopher ..nchpad.net/lbox]% [18:23] wrtp: Your machine seems pretty unfriendly today :) [18:24] wrtp: Ah, could be lpad.. [18:24] niemeyer: the actual error is [18:24] ../goetveld/rietveld/form.go:7:2: import "exp/html": cannot find package [18:25] wrtp: form.go: "launchpad.net/goetveld/rietveld/html" [18:25] wrtp: The package is in the PPA, and the goetveld package doesn't depend on exp/html for a while [18:25] niemeyer: ah! i should remove goetveld [18:25] wrtp: Seems like things are out of date in both fronts there [18:25] niemeyer: pity go get -u doesn't work [18:25] wrtp: Check if you have the PPA configured [18:26] wrtp: apt-get update won't help otherwise [18:26] niemeyer: which PPA is it? [18:26] wrtp: ppa:gophers/go [18:28] niemeyer: ah, that'll be the reason then. i guess it was probably lost when my system upgraded. [18:29] niemeyer: thanks [18:29] wrtp: np [19:18] niemeyer: from the CL: [19:18] "" [19:18] Two options with the current interface - either I add a series [19:18] argument to all the entry points, or I add "WithSeries" variants [19:18] of all the functions. Any preference here before I go off and do the [19:18] wrong thing? [19:18] "" [19:18] have you got a preference here? [19:23] wrtp: Your changes to the actual method interfaces seemed nice [19:23] wrtp: My complaints was only about the whole refactoring on how the helper is instantiated and hooked everywhere [19:24] niemeyer: i wish i'd realised that. it sounded like you didn't like any change to the existing interface. [19:24] wrtp: Having series seems fine [19:25] niemeyer: i think i'll go with reverting everything. it's much less work. [19:25] wrtp: I realize you're trying to fix a problem you found [19:25] wrtp: I was only arguing that the problem you found seems much simpler than the amount of work we've both put on this already [19:26] niemeyer: perhaps that's true. but i've already done that work, and now i have to do quite a bit more to undo it and put in another fix. [19:26] wrtp: Yep, you've already done that work *several* times.. [19:26] wrtp: unfortunately the last incarnation doesn't look good [19:26] niemeyer: twice only. [19:26] wrtp: But I cant' be blamed for not liking every incarnation :) [19:27] niemeyer: i *thought* it was significantly better than the suite idea [19:27] wrtp: There was a simple change in the beginning, then a refactoring, then another refactoring [19:27] wrtp: While all you needed was a series argument [19:29] niemeyer: that's true. sometimes it seems like something is worthwhile when actually it's not. [19:31] niemeyer: BTW there *was* only one refactoring - note that most files have only two versions. [19:32] wrtp: There were pastes before that [19:32] wrtp: But it's ok, it's really not worth arguing further [19:33] niemeyer: agreed. i'm on it now. [19:39] dammit, it's not as easy as i thought. unmerging is a right pain. [21:09] niemeyer: this is trivial, as discussed earlier: https://codereview.appspot.com/6489117/ [21:09] wrtp: I'm half-way through already.. just be ready in a moment [21:09] niemeyer: ta [21:25] wrtp: done [21:28] niemeyer: thanks a lot. [21:29] wrtp: My pleasure, thanks for the fixes [21:30] niemeyer: did you look at the branch i mentioned above (the series argument added to the Repo methods)? it should be trivial. [21:31] niemeyer: (just realised it looks like you might have assumed i was referring to another branch) [21:33] niemeyer: i can submit the authorize-internal-traffic branch which depends on it if it LGTY [21:34] niemeyer: i've discovered a little more about the bizarre bzr behaviour i encountered earlier. it's in the branch in launchpad. if i push to any other branch, it works. [21:37] % lbox propose -wip -req 058-testing-charm-series [21:37] error: Branch check failed: exit status 1 [21:37] ----- [21:37] gofmt is sad: [21:37] environs/jujutest/livetests.go [21:37] yay! [21:37] !! [21:37] wrtp: Hmm, interesting [21:38] LOL [21:38] wrtp: [21:38] https://codereview.appspot.com/6498117/ [21:38] https://codereview.appspot.com/6489117/ [21:38] wrtp: Both are yours :-) [21:39] niemeyer: erm, yes. is there something i should notice there? [21:40] wrtp: The numbers [21:40] niemeyer: cool! [21:40] niemeyer: now i see why you assumed i was referring to a different branch! [21:41] wrtp: RIght :) [21:42] niemeyer: might the "dangling branch reference" be the source of my problem? http://paste.ubuntu.com/1201394/ [21:42] niemeyer: (not that i care any more; i'm abandoning that branch because my prereq has changed) [21:43] wrtp: Uh.. probably [21:43] wrtp: I don't recall seeing that before [21:43] wrtp: review sent [21:43] wrtp: Just suggested inverting the parameters so it matches how we use the two arguments elsewhere (sorry :() [21:43] niemeyer: damn, i wondered about that as i was doing it [21:45] wrtp: Hopefully sed can do it for you [21:45] niemeyer: yeah, i did it before. shouldn't be much hassle. [21:45] niemeyer: structural regexps - even better than sed :-) [21:48] wrtp: Oh? [21:49] wrtp: How does that work? [21:51] niemeyer: http://bit.ly/RSC1iU [21:55] CHeers [22:03] niemeyer: here was my expression for changing the args around BTW. it doesn't really leverage much though - sed would be just as easy here. [22:03] X/./,x/testing.Charms.*"series"\)/s/(,[^,]*), "series"\)/, "series"\1)/ [22:03] niemeyer: but the x pattern is a common one - narrow down scope until you've got something of known form. then hack at it [22:07] niemeyer: it occurs to me that gofmt would probably have been a better approach here! [22:14] niemeyer: gofmt -w -r 'testing.Charms.x(z, a, b) -> testing.Charms.x(z, b, a)' $gofiles [22:15] niemeyer: gofmt rules [22:34] wrtp: Woah [22:34] wrtp: Impressive indeed [22:35] niemeyer: the only thing it failed on was when it was using coretesting not testing [22:59] niemeyer: i think i need a UnitWatcher, same kind of thing as the MachineWatcher. sound reasonable to you? [23:07] hey folks! i'm giving a talk about PaaS and wondering if anyone has a reference for when Juju (or Ensemble, at that time) was first released? I don't see it on either the "about" page or the wikipedia page... [23:08] grantgm: good question. :) [23:09] :) [23:09] grantgm: If you count shipping it in the distro as "first released" then that would be when Ubuntu 11.10 was released [23:09] grantgm: 0.5+bzr398-0ubuntu1 [23:10] hmmm...ok, that sounds like about when I first heard of it. but presumably it was usable via PPA before that, right? [23:11] grantgm: yeah, the first time I saw it was January of 2011, from the PPA [23:11] just want to make sure i'm not short-changing it w.r.t. the big release announcements (before they were really usable) from the other players [23:12] SpamapS, ok, cool, i guess i'll go with that [23:12] SpamapS, thanks! [23:12] grantgm: its still, in many ways, just a tech preview :) [23:12] grantgm: http://juju.ubuntu.com/docs .. says so :) [23:13] well, it's a pretty damn impressive tech preview, then! but really, aren't they all? :) [23:13] SpamapS, thanks again! [23:13] wrtp: Yeah, certainly [23:14] grantgm: It was first seen working even around march 2010 [23:14] s/even/ever [23:14] Erm, sorry [23:14] 2011 [23:15] What SpamapS said, actually [23:15] niemeyer: right, it was in the PPA in January, but we weren't really talking about it until March. :) [23:16] it lived in public obscurity [23:17] SpamapS, niemeyer, ok, so maybe i'll go with March then. That still puts it out ahead of Cloud Foundry (April) and OpenShift (May) :) [23:20] grantgm: I'd be interested to see how you're drawing a comparison between juju and cloudfoundry. [23:20] since.. juju deploys cloudfoundry [23:20] yea, i know it's definitely not a perfect comparison...the first thing i'm talking about is that the definition of paas is very fuzzy [23:21] basically anything in the massive void between traditional IaaS and SaaS gets assigned the PaaS moniker, which is really rather silly [23:21] its a silly human trait [23:21] we can't have groups of 1 [23:22] niemeyer: done: https://codereview.appspot.com/6498124 [23:23] niemeyer: if it's ok i'll hold off on the mstate unit watcher until the generic watcher logic is back in place there. [23:24] davecheney: morning! [23:32] wrtp: hello