[08:57] morning all [09:02] heya TheMue [09:02] fwereade_, TheMue: yo! [09:02] fwereade_: moin [09:03] wrtp: moin [11:43] lunchtime [12:30] Morning all [12:31] niemeyer: moin [12:33] TheMue: Heya [12:41] niemeyer: hiya [12:41] g'morning [12:51] wtf, it's hailing [12:51] wrtp: Any chances of a few additional reviews? You've reviewed the tips but the pre-reqs are blocking them [12:52] this is not why I moved to the med [12:54] niemeyer: i thought i'd reviewed 'em all. [12:54] wrtp: Nope, there are still pending ones in the queue [12:54] niemeyer: one mo, i'll try and remember where the queue page is again... :-) [12:55] wrtp: Meanwhile, I'll code a quick one [12:55] wrtp: TO disable stats so that performance checks do not affect them [12:59] sometimes i want a forward link as well as a backward link, so i can easily find the next review to do... [13:27] niemeyer: done, i think. let me know if i've missed any [13:28] wrtp: You have, the one I'm pushing *right now*! ;-) [13:28] :-) [13:28] wrtp: Should be a breeze, though [13:30] wrtp: https://codereview.appspot.com/6061045 [13:32] niemeyer: wouldn't it be better to have stats enabled by default? [13:33] niemeyer: i.e. disablestats=1 rather than stats!=0 [13:33] wrtp: It is enabled by default.. isn't it? [13:33] niemeyer: it needs the "stats" field in the form to be set, no? [13:33] wrtp: Nope [13:33] wrtp: It needs it to not be set to zero [13:34] wrtp: Note that tests continue passing [13:34] doh [13:35] niemeyer: LGTM [13:35] wrtp: Cheers! [13:35] niemeyer: i still don't see why you can't just use a blank user name in the key BTW [13:36] wrtp: A blank string is a valid token [13:36] rather than having those if statements strewn everywhere [13:36] niemeyer: why's that a problem? [13:37] wrtp: It's a problem because there's no point in having to match it [13:37] wrtp: The data should be foo:bar, not foo:bar:: [13:37] wrtp: Just like the URL is cs:oneiric/hadoop, not cs:~/oneiric/hadoop [13:39] wrtp: hi [13:40] andrewsmedina: hiya [13:40] wrtp: everything ok? [13:40] andrewsmedina: good thanks [13:42] wrtp: I run the ec2 (go port) tests here in my machine, but they are failing [13:42] wrtp: I need to do something to run these tests? [13:42] andrewsmedina: please run with -gocheck.vv and send me the output [13:43] niemeyer: is "cs:~/oneiric/hadoop" valid? [13:43] wrtp: No, it's not.. that was the point [13:44] wrtp: http://paste.ubuntu.com/933966/ [13:44] wrtp: It's need set the AWS envs? [13:45] andrewsmedina: you need to set up an amazon AWS account and set your $AWS_ variables appropriately [13:45] niemeyer: how visible are the keys to users? [13:46] niemeyer: i think that having all charm keys of the form series:name:user: even when user is blank should be ok, if it's not generally visible. [13:46] niemeyer: it would remove quite a few lines of code, at any rate :-) [13:46] wrtp: It doesn't matter.. let's please not be lazy. [13:47] wrtp: The data is oneiric:hadoop.. not oneiric:hadoop:: [13:47] niemeyer: i don't think it's lazy, i think it's appropriate canonicalisation [13:48] wrtp: You're trying to save a couple of lines of code.. I can put that in a function if it bothers you so much, but it shouldn't affect the desired data format that we want [13:48] wrtp: The proper data format is oneiric:hadoop, not oneiric:hadoop: [13:50] wrtp: this for local tests? [13:50] niemeyer, re https://code.launchpad.net/%7Eniemeyer/juju/go-store-blitz-key/+merge/102230 ...I don't quite get what performance is being tested there, it doesn't seem like it'd hit anything very significant? [13:51] fwereade_: wrtp misunderstood the point of that key, and that's of course because I've been extremely vague about it [13:51] fwereade_: This is just a validation key to tell the service we own this site [13:52] niemeyer, ha! ok, that suddenly makes lots more sense [13:52] andrewsmedina: ah, they shouldn't be... that might be a bug. in the meantime, try setting the AWS_ variables to something random and see if it works [13:53] niemeyer: ah! i thought it was used directly as part of a performance test... [13:53] wrtp: No, the goal is to test the real endpoints [13:53] niemeyer: cool, i understand now. i wondered about the strange form of the URL. [13:54] wrtp: That's why we need stats=0 as well [13:56] andrewsmedina: yes, it's a bug. will fix. but for the time being, just do export AWS_ACCESS_KEY_ID=x; export AWS_SECRET_ACCESS_KEY=x; before running the tests [13:57] niemeyer, hmm, it seems like stats=0 is a choice between skewing the stats and skewing the performance data [13:58] niemeyer, and while obviously we don't want to skew the stats, it doesn't feel quite right [13:59] fwereade_: I agree, obviously we don't want to skew the stats :-) [14:00] fwereade_: Hmm.. we can put the IncCounter run in the background, actually [14:00] fwereade_: Which means it won't affect the response timing either way [14:00] wrtp: ok! [14:02] niemeyer, well, it's still load on the server, isn't it, even if it doesn't necessarily directly affect the response time of that query? I'd be happiest if we could switch it to perform a real write to a different place [14:02] niemeyer, but that'll potentially have different characteristics too, so maybe I'm heading up the garden path here [14:03] niemeyer: how about defining a function like this and using it throughout: http://paste.ubuntu.com/933992/ [14:03] wrtp: You're trying to save a couple of lines of code.. I can put that in a function if it bothers you so much, (...) [14:03] wrtp: Yes :) [14:04] niemeyer: it would make me happier, yeah. that "if curl.User" test is in quite a few places. [14:04] wrtp: Sure, will do it [14:05] fwereade_: That feels a bit over the top for the level of traffic we currently have :-) [14:05] niemeyer, yeah, garden path :) [14:06] fwereade_: I'm most interested in knowing which ballpark we're in, and measuring that every once in a while to see how it's going [14:06] fwereade_: It's far from being any kind of issue that would require such care [14:06] niemeyer, indeed [14:06] fwereade_: I appreciate your input though, for real [14:06] niemeyer: i think i agree with fwereade_ that we should in general test the usual path (including stats gathering). but it's useful to be able to turn off stats too, so that we can see how much overhead they impose. [14:07] fwereade_: I will move these calls to the background, and put that with the change wrtp just requested [14:07] niemeyer, perfect, thanks [14:07] niemeyer: sounds good [14:32] fwereade_, wrtp: https://codereview.appspot.com/6063043 [14:32] niemeyer: chunk mismatch :-( [14:32] niemeyer: oh, it's working now [14:32] oh no it's not [14:33] niemeyer, LGTM [14:33] What the heck.. [14:33] (I see no mismatches...) [14:33] Well.. wrtp: https://codereview.appspot.com/6063043/patch/1/3 [14:34] fwereade_: You're probably not looking at the side-by-side [14:34] niemeyer: yeah, that works fine for me [14:35] niemeyer, that is true [14:35] Hmm.. I'll have to add a trick to the test to stabilize it [14:35] niemeyer: i'd implement use the same function in the test. [14:36] wrtp: I prefer to see it in the test [14:36] wrtp: Most of them are constants [14:36] niemeyer: ok [14:37] niemeyer: i'm slightly concerned about the number of background IncCounters there may end up being. depends on the traffic i guess. [14:38] wrtp: They're necessarily proportional to the number of background requests being handled [14:38] wrtp: If incrementing a counter is more expensive than handling the request, something is wrong [14:39] niemeyer: ok, if you're sure about that. [14:40] wrtp: Well, it's more that I can't imagine how either of those statements could possibly be false.. :-) [14:42] niemeyer: only if the IncCounters aren't completing in a timely way and something's hammering the server with a cheap request. [14:42] wrtp: That's addressed by the second point [14:43] niemeyer: indeed. [15:03] Lunch time.. back in a bit to finish merging/applying reviews [16:07] * niemeyer waves [16:13] * wrtp waves back. [16:27] gn all, happy evenings [16:41] fwereade_: Cheers! [16:41] wrtp: I think I forgot a couple of renames you requested, but still have them in mind. Will submit them at the end of the pipeline. [16:41] niemeyer: i was just trying to go back and have a look at the reviews, but my gmail seems to be down. [16:48] niemeyer: still down. let me know here of anything you'd like me to respond to... [16:48] wrtp: I think it's all good in general.. I've agreed to most things you've said [16:48] niemeyer: could you paste a link to the CL please... [16:49] wrtp: I actually didn't miss the review points I mention above either.. they were in the caching branch, which is still not in [16:49] wrtp: Which one the 7-8 ones? :-) [16:49] niemeyer: the more recent one (it has links to the previous ones) [16:49] s/more/most/ [16:50] wrtp: https://code.launchpad.net/~niemeyer/juju/go-store-stats-bg/+merge/102316 [16:51] i'm sure i sent a LGTM for that one, oh well [16:52] wrtp: You did on IRC [16:52] ah, must've forgot to do it on codereview [16:53] just the cache one to go [17:04] Oh, I think I missed what fwereade_ meant in one of his comments [17:16] TheMue: ping [17:30] niemeyer: pong [17:30] TheMue: Heya [17:31] TheMue: Just wanted to see how the branch is coming [17:31] niemeyer: hi, today i have a real splitted day [17:31] TheMue: Did you read my follow up comments yesterday? [17:31] niemeyer: yes, and the changed ChangeWatcher is now in testing and will then go in [17:32] TheMue: Super.. did it feel good while doing the changes? [17:33] niemeyer: it would have been better if the GetW() watch also accepts ZNONODE and later can be used for new created nodes [17:33] niemeyer: but i think i found a way [17:34] TheMue: Cool [17:36] niemeyer: it now also does a re-get if a first get runs on a ZNONODE, does an ExistsW() for the needed watch and stat is not nil (aka somebody has created the node exactly between the get and the exists) [17:36] TheMue: Cool [17:36] TheMue: Does it do a re-exists too, if the node disappears? :-) [17:37] yip [17:37] niemeyer: eh, yup ;) [17:37] TheMue: Hehe :) [17:37] TheMue: Super [17:37] niemeyer: it's a loop waiting for the correct criterias [17:39] TheMue: Makes sense [17:39] TheMue: It's awesome to have that well abstracted away in that compact form [17:40] niemeyer: test looks good [17:47] wrtp: I'm thinking in move cloudinit to environs package. Because it's used for all providers, ec2, local etc [17:48] andrewsmedina: is it used for the local provider? [17:49] wrtp: somethings, like jujuOrigin and other things [17:49] andrewsmedina: i was certainly thinking of moving into the environs package at some point, but i didn't think it was quite time yet [17:50] wrtp: I'm writing the local provider [17:50] andrewsmedina: does the local provider actually execute the cloudinit init script? [17:51] andrewsmedina: i was under the impression that the local environ would execute the agents directly. [17:51] andrewsmedina: (but i'm fuzzy in this area :-]) [17:54] andrewsmedina: i'm going to have to go very shortly BTW, sorry. [17:56] wrtp: ok, can I talk with you about it later? [17:57] andrewsmedina: that would be good. any time tomorrow is fine. i'm online from about 0800UTC [17:58] * wrtp always finds crypto auth errors to be a pain to diagnose. [17:58] wrtp: ok [17:58] niemeyer: as you might guess, i'm actually testing the ssh tunnel stuff. not far now :-) [18:00] "sshd: Failed publickey for rog from 127.0.0.1 port 45416 ssh2" ... but why has it failed? [18:00] time to stop for the day. see y'all tomorrow. [18:00] andrewsmedina: speak tomorrow, i hope [18:00] niemeyer: So, changed watcher is in at https://codereview.appspot.com/6059044 [18:01] wrtp: ok [18:01] wrtp: thanks [18:07] TheMue: Within that loop, I believe the eventType is a red-herring [18:08] niemeyer: could you please explain? [18:08] TheMue: Sure [18:08] TheMue: We used to consider a removal as an error, so we stopped immediately with the event type hint [18:08] TheMue: Now that's not an error anymore [18:09] TheMue: so we don't really care about what is the *last* event that we got. [18:09] TheMue: We care about our ability to get the state *now* [18:09] TheMue: So you can drop the usage of that detail entirely, I believe, and have a cleaner algorithm with the same semantics [18:11] niemeyer: it's a change after a hint of rog. he had a problem with my first approach always trying a GetW() first. his idea has been to skip it if we enter update() with a last EVENT_DELETED [18:12] niemeyer: i've done without it before and it worked fine, so i can easily remove it [18:13] niemeyer: i'll do so and check it in again. or shall i wait until your review? [18:15] TheMue: Hmm [18:16] TheMue: So the idea is to optimize it so that we try to get the current state right first.. [18:18] TheMue: We can simplify it then.. [18:18] TheMue: By moving the "exists bool" into the parameter [18:19] TheMue: This should get rid of most of the extra logic handling the event type [18:19] TheMue: We also don't need a watch variable, btw.. we already have one in scope called nextWatch [18:23] niemeyer: ok, think I've got your ideas, will try it [18:25] TheMue: As a trivial, comments at lines 126 and 133 are replicating the code below them exactly [18:26] TheMue: That's pretty much it as far as the code is concerned.. it looks nice [18:27] TheMue: Will check the tests once you propose again [18:27] Don't expect anything surprising there.. [18:31] niemeyer: fine. and I just fetch an evening beer and can so continue now. *lol* [18:33] TheMue: Sounds like a good plan.. :) [18:33] niemeyer: yeah [18:34] and I'm *almost* at the end of the pipeline [18:35] Or the graph, more precisely :) [18:46] niemeyer: just put some code at the end of the pipeline *smile* [18:53] mthaddon: ping [19:22] so, off for today [20:38] I'm taking a break..