=== meetingology` is now known as meetingology [06:51] morning [06:53] * davecheney waves [06:53] TheMue: https://codereview.appspot.com/6203083 [06:53] coming along [06:54] http://paste.ubuntu.com/998421/ [07:33] TheMue, davecheney: yo! [07:33] rogpeppe: Yo' man. [07:36] davecheney: looking good. one little question: is it possible to start a machine that's already been created? [07:36] davecheney: i mean, will we ever want to actually do that? [07:37] rogpeppe: good question, curretly the start machine and create machine.loop are closely tied [07:38] similarly when a stop is successful, the machine will regestier itself so i can't accept more messages [07:38] *deregister [07:38] davecheney: if we *don't*', then i'm not sure there's a need for the "start" message - we can just start when the machine is created. [07:38] rogpeppe: true, it's probably overengineered as it stands now [07:38] i'm not doing any more work on it this evening [07:39] davecheney: and the loop becomes a single channel receive... [07:39] i'm tyring to fix the tests on https://code.launchpad.net/~dave-cheney/juju/go-watch-machines-topology/+merge/106294 [07:39] davecheney: cool. [07:42] rogpeppe: I also have to implement so kind of backoff logic in there [07:42] davecheney: yeah. [07:42] davecheney: that should be straightforward though - the goroutines mean no state machine is necessary, which should make the logic nice. [07:43] <- time.After(5 *time.Seconds) would do in a pinch [07:44] davecheney: yeah. maybe add a touch of randomness too. [07:45] rogpeppe: i'm thinking a sort of incresing backoff [07:45] that you kind of hint by saying .Success() or .Failed() [07:45] which increases or decreasese the delay [07:45] so if things start to crap out, the delay between attempts grows [07:45] davecheney: if you want to factor out the backoff strategy, you might want to have a look at attemptStrategy in environs/ec2, as a possible API example [07:46] rogpeppe: that sounds like exactly what I want [07:46] davecheney: it doesn't do exponential backoff [07:46] davecheney: but the API works nicely and was much discussed at the time [07:46] all the better to reuse it then [07:48] davecheney: mind you, perhaps you never want to give up, in which case perhaps the API is overkill. [07:51] davecheney: BTW did you see, someone discovered my shell? :-) http://debu.gs/entries/inferno-part-1-shell [07:51] \o/ hacker news [07:54] * rogpeppe never looks at hacker news. one stream too many. [07:56] rogpeppe: Any usage statistics for your shell? Download numbers? [07:56] TheMue: absolutely no idea. probably in the low 20s :-) [07:56] rogpeppe: i was going to say, it's probably not allowed to drink [07:56] TheMue: noone uses it [07:56] rogpeppe: Hehe, not even you? [07:56] rogpeppe: do you know a guy called Chris Collins [07:56] davecheney: occasionally. [07:57] drink? [07:57] davecheney: not that i can remember, why? [07:57] he's a plan 9 fan here in AU [07:57] he's also a hardware hoarder like you [07:58] davecheney: problem is inferno lives in a walled environment. it's great for dealing with stuff inside that environment, but not great if you want to interact with the host system [07:58] davecheney: i am *not* a h/w hoarder :-) [07:58] davecheney: i just have a NeXT! [07:59] rogpeppe: can the watcher.ContentWatcher return "" ? [07:59] ie, return spuriously [07:59] davecheney: it could return "" if the contents were "" [08:00] what if ther were "" before [08:00] davecheney: and i think if there's an error, the channel will be closed [08:00] the problem i'm having atm is the watcher fires once, but the contents don't change [08:00] so it gets out of phase with what the test expects [08:00] davecheney: if the contents don't change, the watcher shouldn't fire [08:00] davecheney: is that what you want? [08:00] let me check the channel isn't closing [08:01] watcher channel closed [08:01] watcher_test.go:275: [08:01] sonovabitch [08:01] ok, let me find out why [08:06] btw, /usr/share/zookeeper/bin/zkCli.sh [08:07] ^ i'm sure you guys know about his [08:07] this [08:08] davecheney: it's really nasty. i wrote my own little cli for it. [08:08] watcher channel closed: watcher: can't get content of node "/machines": zookeeper: existsw "/machines": zookeeper is closing [08:09] urg [08:09] rogpeppe: it is really nasty, you can't set a key that contains whitespace [08:09] davecheney: nice informative error message though :-) [08:09] davecheney: *really*!? [08:09] davecheney: omg that's not nice [08:09] rogpeppe: really. [08:10] rogpeppe: i ended up adding code into the provisionng agent to populate zk for me [08:10] as a test [08:10] davecheney: oh, you mean the cli shell script [08:10] davecheney: i thought you meant zk proper [08:10] rogpeppe: nah, just zkCli [08:11] davecheney: if you look at it, it's got so much abstraction in it it's not true. not worth using. [08:11] davecheney: definitely written by a jobsworth. [08:15] rogpeppe: right, problem fixed, was watching the wrong key [08:15] but now I have another problem [08:15] ... obtained *state.MachinesChange = &state.MachinesChange{Added:[]*state.Machine{(*state.Machine)(0xf8400c9360)}, Deleted:[]*state.Machine(nil)} [08:15] ... expected state.MachinesChange = state.MachinesChange{Added:[]*state.Machine{(*state.Machine)(0xf8400daf00)}, Deleted:[]*state.Machine(nil)} [08:15] davecheney: that's an easy one to fix [08:15] *Machines don't define equility [08:16] davecheney: just expect the pointer type [08:16] davecheney: it's doing DeepEquals, right? [08:16] mm [08:16] * davecheney reads the godoc for gocheck [08:25] * TheMue moved his office to the veranda due to the beautiful weather today. [08:42] TheMue: the weather *should* be beautiful today, but the haar has come in. dull again. [08:44] rogpeppe: We are to far away from coast for haar (about 50 to 80 km, depending on if the Jadebusen, a bay, is seen as coast too). So now it's sunny and warm. [08:44] s/to far/too far/ [08:44] TheMue: we had the first decent sunshine in ages yesterday. [08:46] rogpeppe: Hehe, that's England. ;) But we're also not very spoiled by the sun here. [08:46] TheMue: it has been *particularly* bad in the last month. [08:48] rogpeppe: We had a short sunny interrupt in March, but in total the spring is too late this year. [08:48] TheMue: same here. must be the same across most of northern europe, i'd guess [08:48] rogpeppe: Yep === TheMue_ is now known as TheMue [12:37] Hello jujuers! [12:40] niemeyer: Heya [13:25] evening. [13:28] Aram: Heya [13:49] niemeyer: morning [13:58] niemeyer: hiya [14:00] Hey guys [14:02] niemeyer: I sent the code for review [14:02] andrewsmedina: That's great, thank you [14:02] niemeyer: :D [14:07] rogpeppe: ping [14:07] niemeyer: pung [14:07] rogpeppe: Yo [14:08] rogpeppe: Just wondering what's the status of your branches [14:08] niemeyer: how's tricks? [14:08] rogpeppe: You've mentioned you had a pre-req that was being merged in [14:08] niemeyer: yeah, you LGTM'd that and i submitted on friday. [14:08] rogpeppe: Is the branch named trunk (!?) ready for review? [14:08] rogpeppe: Right, but did you repush the follow up? [14:08] s/repush/re-proposed/ [14:08] niemeyer: ahem, forgot to branch -m that one [14:08] niemeyer: i *think* that was an orthogonal branch. let me check. [14:09] rogpeppe: Ok, just want to make sure I'm not reviewing something you don't want me to [14:09] niemeyer: yes, i'd love a review of that on if poss. [14:10] rogpeppe: Sounds good, starting right away [14:10] niemeyer: if i was able, i'd rename the branch "go-environs-simplify-provider-interface" [14:10] rogpeppe: Cool, no worries [14:10] niemeyer: i think you'll like it BTW [14:11] rogpeppe: Sweet [14:12] rogpeppe: As an unrelated note that I just reminded, I pushed a goamz branch over the weekend to improve and fix s3 a bit [14:12] rogpeppe: I gave a try at using it for dreamhost's Objects service.. works! [14:12] niemeyer: yeah, i'm intending to look at it. sorry about the breakage BTW! [14:12] rogpeppe: I mean, with the branch.. [14:12] rogpeppe: No worries.. I think we all just have to be more diligent at running tests pre-submit [14:13] niemeyer: maybe lbox submit's auto-merge functionality is really unnecessary, 'cos you should merge and test before submitting anyway [14:15] rogpeppe: Turns out it's quite boring to do that by hand all the time [14:15] niemeyer: yeah, i guess. [14:16] rogpeppe: I know for sure.. been there :) [14:16] (for years!) [14:16] niemeyer: but it certainly makes it easier to submit broken code... [14:16] rogpeppe: It makes it easier to submit any code.. broken or not [14:16] rogpeppe: Making that process more painful isn't a great way to solve the issue [14:18] niemeyer: case: i merge, test, someone else submits a change to an API i'm using, i submit, lbox auto-merges => broken build. [14:18] niemeyer: Any chance to take a look at https://codereview.appspot.com/6200044/ ? [14:18] niemeyer: the gap between me testing and me submitting can be arbitrarily short [14:18] TheMue: There are great chances, yeah :) [14:18] TheMue: I've been reviewing the queue regularly [14:19] TheMue: So if it's in the active branches list, it will get reviewed [14:19] niemeyer: Just wondered, because you already reviewed a follow-up. [14:20] rogpeppe: Sure, that's a problem.. let's fix it. We can do that without making our lives more painful. [14:20] niemeyer: Right now I've finished Add…Relation() with tests as a next branch. [14:20] TheMue: Yeah, as I said, I've been reviewing regularly [14:20] TheMue: Every day [14:20] niemeyer: is there a way to fix it without getting lbox to run the tests itself? [14:20] TheMue: I've also been ordering reviews by branch size [14:20] TheMue: If you want faster turn arounds, smaller branches will win [14:21] niemeyer: OK [14:21] i was thinking that branch size should be judged by bzr diff | grep '^>' | wc -l [14:21] rogpeppe: Branch sizes is ordered by diff size [14:21] otherwise we get penalised for many small changes, and also for deleting code [14:21] rogpeppe: https://code.launchpad.net/juju/+activereviews shows the number of lines [14:23] rogpeppe: Eventually we can have that.. we'll have to write logic that checks out branches, analyzes them, and builds a list in our preferred fashion [14:23] rogpeppe: Meanwhile, Launchpad has that nice column :-) [14:56] rogpeppe: Very nice indeed [14:56] niemeyer: cool, thanks [14:56] rogpeppe: Some trivial suggestions only [14:56] niemeyer: am just currently doing the awkward merge between that branch and the one submitted on friday [14:58] TheMue: Ah, I've already reviewed most of that branch on Friday, btw [14:58] niemeyer: i'm a bit surprised that goyaml conventions for naming are different from json and xml [14:58] TheMue: I've purposefully not submitted the review because I wanted to look through it again after the weekend [14:59] TheMue: You've (silently?) refactored significantly the way Python stored information about the endpoints, and I want to see that again with a fresh mind today [14:59] niemeyer: that case changing stuff was deliberately removed from them to make the mapping clearer, i think. [14:59] niemeyer: i'll remove the tags anyway though [14:59] niemeyer: Yes, that's a result of the discussion between William and me during UDS. [15:00] TheMue: Ok, this is a major change, though [15:00] TheMue: It shouldn't be submitted silently, without even a note in the description [15:01] TheMue: I'm still thinking through it. At this point just saying I'd appreciate a note next time. [15:01] niemeyer: OK, will handle it more carefully next time. [15:01] TheMue: Thanks [15:01] rogpeppe: xml had stuff that was a *lot* more magical [15:02] rogpeppe: json too, IIRC [15:02] niemeyer: still, i do like the "no magic at all" approach [15:02] niemeyer: it makes the code more transparent. [15:02] IMHO [15:02] rogpeppe: There's no magic in goyaml.. it's the lowercased name. [15:02] rogpeppe: If it doesn't match, it doesn't [15:02] niemeyer: does that mean you can't marshal to an Uppercased name ? [15:03] rogpeppe: That no [15:03] rogpeppe: Erm [15:03] rogpeppe: No [15:03] niemeyer: so it applies in one direction but not the other? [15:03] rogpeppe: If you want that, you need to use a tag [15:04] rogpeppe: It makes sense (to me, anyway) because most yaml is lowercase [15:04] niemeyer: i'll remove the tags, but let me lodge an objection for the future. it's nice if marshalling packages are consistent like this. [15:04] rogpeppe: Same thing with mgo [15:04] rogpeppe: MongoDB is massively lowercase [15:04] rogpeppe: So goyaml and bson are consistent ;) [15:04] niemeyer: i think having a non-bijective transformation is asking for trouble [15:05] rogpeppe: Not sure about what you mean. I've just said it's bijective. [15:05] rogpeppe: The marshaling name is the lowercased field name. [15:06] niemeyer: ah. so i *can't* marshal to an upper-cased name? [15:06] rogpeppe: You have to use a tag name. [15:06] Erm.. s/name// [15:06] niemeyer: i see. [15:06] niemeyer: sorry, i misunderstood [15:06] niemeyer: that's not too bad, i guess. [15:07] rogpeppe: Yeah, that's how I feel too. [15:07] Anyway, lunch time [15:07] Back in a bit [15:07] TheMue: Will cover your branch first thing in the afternoon [15:08] niemeyer: Thx a lot [15:16] niemeyer: not sure about "LoadConfig" as a name. how about NewConfig ? [15:29] rogpeppe: +1 [15:29] niemeyer: cool, done already :-) [15:47] niemeyer: you might want to have a brief once-over of environs/interface.go before i submit, as i didn't quite use the comment text you suggested. [15:55] lunch [16:09] rogpeppe: Looking again. [16:14] rogpeppe: Replied === Guest___ is now known as smaddock [16:18] niemeyer: thanks. actually i think it can be simpler still: // Every provider must accept the "name" and "type" attributes, the environment name and provider type. [16:19] rogpeppe: That's misleading. It's not A and B, C and D. [16:19] rogpeppe: If you're happy with the suggestion, can we please go with it? [16:20] niemeyer: i'm not keen on the "with" in your suggestion. am trying to think of a better phrasing. [16:20] rogpeppe: Alright, please use whatever you fancy then [16:20] rogpeppe: If "with" is unacceptable I can't really improve on it [16:21] niemeyer: it reads oddly, sorry, i can't quite say why. [16:21] niemeyer: how about "Every provider must accept the name of the environment ("name") and the environment type ("type")." [16:21] rogpeppe: Sucks [16:22] hrm [16:22] niemeyer: what about s/with/holding/ [16:22] ? [16:22] rogpeppe: "provide the foo argument with the key" is extremely usual [16:23] rogpeppe: holding is equally usual [16:23] rogpeppe: (which means, I'm fine with it too) [16:24] niemeyer: cool, i'll go with that, and ponder why my "awkward-english" alarm went off for "with" :-) [16:24] rogpeppe: Please let me know if you find out [16:24] rogpeppe: and thanks [16:24] So, off for the moment. Next branch is in. [16:25] niemeyer: something to do with the fact there are two keys, i think. [16:25] niemeyer: but can't pin it down more than that... [16:26] rogpeppe: Doesn't parse as related in my head [16:26] or, as Kevin would say, in my "heeeed" [16:26] :-) [16:29] niemeyer: in the end, i'm not really sure how "holding" is better than "giving", but i'm going with it anyway. [16:29] rogpeppe: It doesn't *give* anything to anyone.. it contains, and is. [16:31] niemeyer: one use of the word "give" is "to impart or communicate" [16:32] niemeyer: which is how i was using it. [16:32] rogpeppe: Try to put "communicates" or "imparts" there.. [16:32] rogpeppe: It's bad too. [16:32] / Every provider must accept the "name" and "type" attributes, communicating the environment name and provider type respectively. [16:33] seems to work ok to me. [16:33] apart from the length of "communicate" :-) [16:33] rogpeppe: Still sounds bad to me. But we don't have to agree on that. [16:33] niemeyer: it's fine. i'll try to avoid it in the future... [16:34] rogpeppe: Thakns [16:40] niemeyer: submitted. thanks a lot for the review. [16:44] rogpeppe: np [16:53] robbiew: Do you know if we'll have that meeting in 7 mins? [16:53] no clue...I can't make it due to a conflict though [16:53] niemeyer: it looks like a lot of folks declined, so perhaps not [16:54] robbiew: There are 20 people in that call.. it seems likely that lots of folks will decline :) [16:54] lol [16:54] good point [16:56] niemeyer: micro branch for review: https://codereview.appspot.com/6219054 [16:56] rogpeppe: Neat, LGTM [16:56] niemeyer: thanks [16:57] niemeyer: yay, fastest turnaround ever! [16:57] rogpeppe: Small branches FTW! :-) [17:40] niemeyer: a larger branch for review: https://codereview.appspot.com/6198064 [17:40] rogpeppe: Cheers [17:40] niemeyer: though it's not nearly as large as it appears. [17:41] niemeyer: i'm off for the day. see you tomorrow! [17:41] rogpeppe: Have a good one [22:04] Stepping out for a while [23:06] gt