[01:54] wallyworld: can you get to launchpad atm ? [01:55] * wallyworld checks [01:55] davecheney: appears ok, what error are you seeing? [01:55] https://launchpad.net/juju-core times out [01:55] works quickly for me [01:56] maybe they were doing a deployment? [01:56] still broken? [01:56] yup [01:56] trying from another site [01:56] oh, finally [01:56] good luck [01:56] \o/ [01:56] launchpad is slow as fuck for me most days [01:56] but this was unusually lethargic [01:57] it's not bad for me [01:57] there's been a lot of work into performance improvements over the last 12 months [01:57] what times to they schedule deployments ? [01:57] if you have any particular pages that are slow, let me know and i'll look into it [01:58] everythign is slow for me [01:58] no down time deployments are done as needed, and should be transparent [01:58] 2-5 second page loag times [01:58] multiple locations [01:58] multiple computers [01:58] fast down time deployments are done 3 times a day and result in about a 2 second outage [01:58] juju-core just loaded for me in 1 second [01:59] cold [01:59] maybe your connection has higher latency to the data centres? [01:59] https://launchpad.net/juju-core/+milestone/1.9.3 4 seconds [01:59] 0.52 for me [02:00] i'm on iinet, your on tpg [02:00] yeah [02:00] neither of those are top shelf isps [02:00] nope [02:00] but this happens for me from different locations [02:00] but cheap :-) [02:00] different computers [02:00] was in melbourne over the weekend on optus cable [02:00] same [02:00] hmmm. i can't easily explain the difference [02:00] don't worry [02:01] i'm used to it [02:01] :-( [02:01] makes it hard to work efficiently [02:01] yup [02:02] the guys are focused on performance issues, but they do need more than one data sample to be able to do anything concrete [02:02] especially if it is not slow across the board [02:02] who should I complain too ? [02:02] Purple squad is on maintenance and hang out in #launchpad-dev - they are very responsive [02:03] another option is to go to a page on qastaging.launchpad.net and turn on tracing, i can help you with that if you want [02:04] qastaging is slower than prod, but it may show some issues worth looking at [02:04] have you checked your latency to the data centre? [02:04] http://d.pr/KwdU [02:05] http://d.pr/i/JVOI [02:05] solid 312ms [02:06] anyway, it's not your job to debug lp problems [02:06] thanks for checking [02:08] no problems, but it would be nice to sort it out [02:09] davecheney: so, out of interest, in the light blue bar, what's the waiting time vs connecting time? [02:10] connection and ssl neg is in excess of 2.5 seconds on the second screenshot [02:10] i have no idea how you are negoating faster [02:10] it's a function of rtt [02:10] wallyworld: you're using firefox, right ? [02:11] davecheney: so, the 1.6s time i gave comes from an ajax info widget on lp, which i think developers get. i also have the connect time like you [02:11] dunno how you got, 12:59 < wallyworld> 0.52 for me then [02:12] my graph says a waiting time of 2.2 seconds, and lp tells it it spent 1.6 seconds processing, so that leaves 0.6 seconds to get the data back to my browser i guess [02:12] that 0.52 for +milestone above was also the lp reported processing tim [02:13] all lies i tell ya! [02:13] anyway, seriously, i don't care about this [02:13] slow I can handle, as long as it's not down [02:14] fair enough. as a data point then, my connect time (incl ssl) is around 1.5, lp render/processing time is between 0.5 and 1.6, and receiving data to browser takes about 0.3 [05:50] ping https://codereview.appspot.com/6855101/ [05:57] davecheney: i'd +1 it but i fear i don't know enough to be able to offer anything worthwhile. it looks ok to me though [05:57] wallyworld: thanks [05:57] you coudl always dist-upgrade and test it :) [05:57] want me to +1 it anyway? [05:57] i'm on quantal already [05:58] do the juju tests pass for you ? [05:58] let me test it then [05:58] i have not run them, will do so now [05:58] i've just been running goose tests [05:58] go test launchpad.net/juju-core/... [05:58] yeah, will do after i merge your branch [05:58] nah, do it before [05:58] otherwise you won't know if I fixed anything [05:59] ok, need to pull tip first [05:59] go get -v launchpad.net/juju-core/... will do that for you [05:59] if you haven't already checked it out [05:59] i have the code checked out etc, i'm just used to using bzr [05:59] is go get the preferred way? [06:00] if you have never checkout out the code, it is a fast way to get all the deps [06:00] if you already have a working copy [06:00] it'll screw it up royally [06:00] yeah, i have everything checked out and built [06:00] i used go get right at the start [06:00] +1 [06:01] i have trunk under a cobzr branch called trunk [06:01] so whenever I want to know what others are doing i do [06:01] cobzr switch trunk ; cobzr pull [06:01] yeah, me too [06:02] was, http://bazaar.launchpad.net/~gophers/juju-core/trunk/view/head:/README useful at all ? [06:02] i used to use light weight checkouts etc, and bzr switch, but am trying cobzr [06:02] it stores the branches in a hidden dir which is both convenient and annoying [06:03] davecheney: yes! i used that to get going [06:03] cool [06:03] glad it was useful [06:03] thanks for writing it :-) [06:03] np, you can/should/might steal it for goose [06:03] yeah [06:03] ok, tests fail as expected [06:03] now to try your branch [06:03] huzzah! [06:03] it'll be whinging about can't find tools [06:04] no, from memory the actual error is it can't find a suitable ami to 'fake' boot [06:04] this change fills in the fixtures to make that happen [06:05] error was: cannot find image satisfying constraints: error getting instance types: 404 Not Found [06:05] wallyworld: yup, that is the error [06:10] davecheney: tests running but taking a loooooong time - appears hung running the updated test [06:11] ie nothing after "ok launchpad.net/juju-core/environs/config 0.373s" [06:13] presences tests take over 70 seconds on my machine [06:13] gocheck reports when the test is done, not when it starts [06:13] check top [06:13] you should see a number of someting.test processes running [06:13] davecheney: what do i look for? [06:14] a child of a process call go [06:14] │ ├─bash───go─┬─2*[6g] [06:14] │ │ ├─container.test─┬─mongod [06:14] │ │ │ └─2*[{container.test}] [06:14] │ │ ├─downloader.test───4*[{downloader.test}] [06:14] │ │ └─9*[{go}] [06:14] something like this, if pstree is your poison [06:14] i have a dummy.test [06:15] from memory the default test timeout is 120s [06:15] it'll fail eventually [06:16] ok, it's been a fair bit longer [06:17] gotta go [06:17] will be online in an hour or so [06:17] if tests are fucked, email juju-dev with the output [06:17] or raise an issue [06:17] ok, bye [06:18] just died now! [06:22] but works when run again [07:47] Morning. [08:05] mornings [08:14] fwereade, davecheney: Hiya. [08:14] TheMue, davecheney, morning [08:17] Our new https://juju.ubuntu.com really looks good. [08:24] morning [08:46] fwereade, TheMue: mornin' [08:46] Hello, Mr Peppe [08:50] rogpeppe, heyhey [08:51] rogpeppe, you know the TxnRevno field, that we need to use to start document watches? [08:51] fwereade: yeah [08:51] rogpeppe, it appears to me as though you can *actually* just pass 0 and it'll still work anyway [08:51] fwereade: except you'll maybe get an event you don't need, right? [08:51] rogpeppe, I guess that perhaps you'll get an extra event sometimes [08:52] fwereade: maybe you don't care though [08:52] rogpeppe, it doesn't have any macro-level effects that I am sophisticated enough to detect [08:53] fwereade: it would mean doing strictly more work on restart [08:53] rogpeppe, yeah, I'm not proposing actually doing it [08:53] rogpeppe, the actual problem is that I was trying to use it, and doing it wrong, and couldn't see that from my tests [08:53] fwereade: interesting thought though - we might decide the simplicity is worth the network traffic [08:53] rogpeppe, and I am wondering if there's any way I can reliably goose it into doing the wrong thing [08:54] fwereade: it's just an optimisation, right? [08:54] rogpeppe, I dunno -- first time I used the API I just bunged 0 in and niemeyer was most unimpressed [08:54] lol [08:55] fwereade: well, the API doesn't actually give you the values - it just tells you that something has changed, no? [08:55] rogpeppe, I forget [08:55] rogpeppe, .Id is all I ever look at [08:55] fwereade: if that's true, it's never going to make any difference as long as you get at least the required events [08:56] fwereade: BTW, i've got a couple of CLs you might want to have a glance at if you fancy it. first is: https://codereview.appspot.com/6854107/ [08:56] rogpeppe, indeed -- anyway, I just thought it was interesting [08:57] fwereade: second is https://codereview.appspot.com/6856105/ (which is the last in the series) [08:57] fwereade: in terms of seeing problems, you'd see problems if the revno field was too high [08:57] rogpeppe, yeah [08:57] fwereade: so you might be able to goose it that way [08:58] rogpeppe, not from outside I think [08:58] fwereade: aren't you storing revnos in files? [08:58] rogpeppe, the problem was that I used the txnrevno field, instead of txn-revno, and got 0 every time [08:58] rogpeppe, I am but that's in a different area [08:59] fwereade: yeah, in that case, i'm not sure i can think of a test that makes any difference. [08:59] fwereade: 'cos if it's zero, you'll get a spurious first event, find that there's nothing to do, then do nothing [09:00] rogpeppe, you might be interested to take a look at https://codereview.appspot.com/6850105/ and https://codereview.appspot.com/6851110/ while I read yours properly [09:00] rogpeppe, yeah, exactly [09:00] fwereade: looking [09:02] fwereade: ah, i had taken a look at the first - i had one unpublished comment [09:03] fwereade: LGTM [09:03] rogpeppe, cheers, you have one too [09:04] s/dong/ding/ lol [09:05] fwereade: thanks [09:10] rogpeppe, and another LGTM, that look fantastic [09:10] fwereade: thanks! [09:12] fwereade: the window really is very short indeed. i think it must be on the order of <0.1s [09:12] fwereade: i've seen the "unauthorized access" problem precisely once [09:17] rogpeppe, fantastic [09:18] fwereade: basically the remote client and bootstrap-state are both racing for first access to the mongodb [09:18] rogpeppe, ah, right, ofc [09:19] fwereade: we're more likely to see the problem now because mgo redials about twice a second [09:49] jam, mgz: would you take a look https://codereview.appspot.com/6851112/ pls? [09:51] dimitern: looking [10:15] rogpeppe, fwereade: Would you take a look at https://codereview.appspot.com/6853075/? I changed and simplified the way it's working. [10:16] TheMue: looking [10:16] dimitern, jam: Good morning. [10:16] morning TheMue [10:16] TheMue: morning [10:19] dimitern: done [10:20] jam: thanks [10:25] TheMue: i like the idea (of just sourcing the file), but i'm not sure that env is the right way to print the env vars [10:25] TheMue: what happens if one of the vars has a newline in? [10:26] rogpeppe: Good hint, yes. [10:27] rogpeppe: Todays Py code is only grepping two values, but as a general purpose package I would like to provide all. [10:28] rogpeppe: Do you know a command to get the names of all environment variables? [10:28] TheMue: you could use awk [10:29] rogpeppe: Uuuh, last time I used awk has been last century. ;) [10:31] TheMue: something like this might do the job: [10:31] awk 'BEGIN {for(v in ENVIRON){s = ENVIRON[v]; gsub("\\", "\\\\", s); gsub("\n", "\\n", s); printf("%s=\"%s\"\n", v, s)}}' [10:31] TheMue: then you could use strconv.Unquote to read 'em in [10:32] jam: dimitern: mgz: wanna have the standup now? [10:32] rogpeppe: Thx, I'll try. [10:32] works for me, is mgz here? [10:32] TheMue: there's probably a better tool around for doing this though [10:32] TheMue: you may even be able to use bash directly [10:33] wallyworld: I'm in mumble [10:33] wallyworld, jam: I'm ok with that [10:33] * wallyworld opens mumble [10:34] jam: dimitern: i've hit that mumble bug again where it won't start, i have to reboot, give me a sec [10:34] ha that's funny, you learn something new every day. i always thought that $'foo' was the same as $foo [10:37] rogpeppe: do you mean $foo vs '$foo' ? [10:37] I haven't really seen $'foo' before. [10:37] jam: no [10:37] jam: neither had i [10:37] jam: except in rc [10:37] jam: and i'd presumed sh was similar like that [10:38] jam: try: echo $'foo\nbar' [10:45] TheMue: looks like "typeset -p -x" might give you what you need [10:46] rogpeppe: Looks nice, yes. [10:47] rogpeppe: Just fetched my old shell programming book. ;) [10:47] TheMue: alternatively, you could just parse the file. it wouldn't be too hard. [10:48] rogpeppe: Which one? The /etc/default/lxc? [10:48] TheMue: yeah [10:48] rogpeppe: Values in it could be based on environment variables too. ;) [10:49] TheMue: that's not too hard either [10:49] TheMue: os.Expand might help [10:49] TheMue: hmm, i dunno. at least using typeset you're guaranteed a standard format [10:50] TheMue: i wonder about the security implications of sourcing the shell script, but since it's in /etc, it's probably ok [10:50] rogpeppe: Yes, here this approach seems better. I started with parsing. But niemeyer had remarks. [10:51] rogpeppe: The Py code just sources it too. [10:51] TheMue: ok, that's interesting. [10:51] TheMue: what values do you need from it, BTW? [10:52] rogpeppe: For Juju only two, LXC_BRIDGE and LXC_ADDR. So they grepped it from env. But golxc is intended to be more general. So I would like to provide them all. [10:55] TheMue: one issue with your current approach is that you'll see env vars that are defined in the testing environment too AFAICS [10:55] TheMue: i think you need to start the shell command with a clean environment [10:56] rogpeppe: I'm sourcing an own file with self-defined values for testing. [10:57] rogpeppe: It's a copy, but with different values than the default values. [10:57] rogpeppe: At least some of them. [10:58] TheMue: i bet if you defined LXC_BRIDGE in your shell and deleted it from the "env" var, your test would still pass [11:00] rogpeppe: If it has the right value, yes. :/ [11:06] jam: mgz: test one two three [11:06] ta! [11:39] Yo! [11:39] hey! [11:45] mgz: Heya [11:45] mgz: When's our next squash game? :-) [11:47] well, that would be one excuse for a holiday in brazil :) [11:47] mgz: Consider yourself invited :) [11:48] mgz: Just yesterday I was playing a pretty good match against a friend and reminding of that game in Copenhagen.. it was great [11:48] fwereade: Heya [11:52] fwereade: https://codereview.appspot.com/6850105 is ready to go in [11:52] niemeyer, sweet! tyvm [11:52] fwereade: Thank you! [11:59] * dimitern => lunch [12:02] * fwereade also [12:11] niemeyer: morning! [12:39] rogpeppe: Found an even simpler way. Wonna look again? [12:40] TheMue: sure [12:40] rogpeppe: Thanks. [12:43] TheMue: what are those double quotes doing at the start of script? [12:44] TheMue: (printenv -0 looks good BTW) [12:44] rogpeppe: Otherwise it isn't passed to sh as one argument. I wondered too. [12:45] TheMue: huh? [12:45] TheMue: have you tried it without them? [12:45] rogpeppe: Yep. [12:46] rogpeppe: Aargh, you meant now double quotes. [12:46] rogpeppe: That works, will remove and repropose it. *facepalm* [12:46] TheMue: s/now/no/ ? [12:46] rogpeppe: Yep, fingers too fast. ;) [12:48] rogpeppe: So, removed. Took them too automatically. [12:49] TheMue: I think we should move on to MAAS instead of continuing to spend cycles on this [12:50] niemeyer: I'm reading the MAAS source in parallel. The remaining two branches are really small and you would do me a favour if I could complete them. [12:51] TheMue: I'd agree if they were ready to land, but last time I've seen there were several issues, so it spends your time, my time, Roger's time, for a branch we won't be using any time soon [12:52] niemeyer: OK, but could you please take a look today to see if the direction now is better? [12:55] TheMue: What happens if there is an LXC variable in the Go process? [12:57] niemeyer: i've raised that issue [12:57] niemeyer: Ah, yeah, IC. That's a problem in the Py code too, but there only for LXC_ADDR and LXC_BRIDGE. /etc/default/lxc overwrites the processes variable. [12:58] TheMue: you've got some more comments [12:58] rogpeppe: Thanks. [12:58] niemeyer: i think it should clear environment variables before sourcing the shell script [13:03] rogpeppe: The sourcing is only in a subshell for reading the values. [13:03] TheMue: that subshell inherits environment variables from the caller [13:03] TheMue: That's not how environment works [13:04] What roger said [13:04] niemeyer: Wanted to express that for the execution of lxc commands the environment is unchanged. [13:05] TheMue: I don't understand how that changes the points made [13:05] TheMue: A child cannot change a parent's environment, ever [13:05] TheMue: But I'm not sure if that's what you're saying [13:05] I mean, at least in computing [13:06] IN the real world a child revamps a parent's environment in its entirety [13:06] niemeyer: *lol* [13:06] niemeyer: Yes, I know. I'm only using the way of the Py code to read values out of /etc/default/lxc [13:07] niemeyer: Here they've done the same, but grepping only for the LXC_ values to then read ADDR and BRIDGE. [13:07] TheMue: Still doesn't change the points made [13:08] TheMue: and the point is reather simple really [13:08] rather [13:09] niemeyer: IMHO sourcing that file overwrites the processes environment when fetchiing the values out of it. Am I right? [13:09] niemeyer: i think it should clear environment variables before sourcing the shell script [13:09] TheMue: that subshell inherits environment variables from the caller [13:09] TheMue: This is right [13:10] niemeyer: So the environment I'm parsing is too large, but it contains the values of /etc/default/lxc. Still right? [13:11] niemeyer: And by clearing the environment before I would reduce it to the values of that file. [13:12] TheMue: Right [13:14] niemeyer: OK, then I know where we gor our wires crossed. (You say so?) [13:14] s/gor/got/ [13:35] rogpeppe: Can you please have a look at William's follow up when you have a second: https://codereview.appspot.com/6851110 [13:35] Well, 10 minutes perhaps [13:35] :) [13:35] niemeyer: will do [13:35] rogpeppe: Thanks [13:52] rogpeppe: One branch reviewed and double LGTMed with trivials [13:52] rogpeppe: Only one left in the queue.. will get to that after lunch [13:52] niemeyer: thanks! [13:52] niemeyer: whee! [13:53] * rogpeppe should have some lunch too [13:53] +1 [13:53] :) [14:45] rogpeppe, ---------------------------------------------------------------------- [14:45] FAIL: cert_test.go:50: certSuite.TestNewCA [14:45] cert_test.go:60: [14:45] c.Assert(caCert.NotAfter.Equal(expiry), Equals, true) [14:45] ... obtained bool = false [14:45] ... expected bool = true [14:45] ---------------------------------------------------------------------- [14:45] FAIL: cert_test.go:66: certSuite.TestNewServer [14:45] cert_test.go:81: [14:45] c.Assert(srvCert.NotAfter.Equal(expiry), Equals, true) [14:45] ... obtained bool = false [14:45] ... expected bool = true [14:45] ---------------------------------------------------------------------- [14:45] FAIL: cert_test.go:95: certSuite.TestVerify [14:45] cert_test.go:104: [14:45] c.Assert(err, IsNil) [14:45] ... value x509.CertificateInvalidError = x509.CertificateInvalidError{Cert:(*x509.Certificate)(0xf8400892c0), Reason:1} ("x509: certificate has expired or is not yet valid") [14:45] OOPS: 3 passed, 3 FAILED [14:45] --- FAIL: TestAll (1.96 seconds) [14:45] FAIL [14:45] FAIL launchpad.net/juju-core/cert 1.974s [14:45] rogpeppe, on trunk -- should I install something? [14:46] fwereade: hmm, passes for me [14:46] fwereade: i'll try against a different go version [14:46] rogpeppe, I'm still using 1.0.2 [14:46] rogpeppe, (er, did we decide to standardize on 1.0.3?) [14:47] fwereade: i'm not sure [14:47] fwereade: i think maybe 1.0.2 as that's what's bundled [14:47] rogpeppe, ah, yes, then I did that deliberately [14:47] * fwereade looks around shiftily [14:49] * rogpeppe builds 1.0.2 [14:49] fwereade: it passes on 1.0.3 BTW [14:50] rogpeppe, I did indeed assume you wouldn't have merged stuff that didn't work for you ;) [14:50] fwereade: i was compiling against tip, so it may not have [14:50] fwereade: hmm, 1.0.2 passes for me too [14:51] * fwereade can't keep up with the cool kids and their crazy avant-garde go versions [14:51] * fwereade goes off to run it more verbosely [14:51] fwereade: could you get it to print out the actual times you're seeing, please [14:52] fwereade: i.e. c.Logf("cert notafter: %v, expiry: %v", caCert.NotAfter, expiry) [14:54] rogpeppe, cert notafter: 2012-11-29 14:53:57 +0100 CET, expiry: 2012-11-29 15:53:57 +0100 CET [14:54] rogpeppe, the otherone's equivalent [14:55] fwereade: interesting. something to do with daylight savings [14:55] rogpeppe, and/or timezones :) [14:55] fwereade: yeah [14:55] rogpeppe, anotheradvantage of the distributed team :) [14:56] fwereade: yeah. i am GMT atm so particularly vulnerable to that kind of error [14:59] rogpeppe, I will assume that the fix will be simple but not immediate, and merge over the top of it, ok? [14:59] * TheMue wonders …oooOOO( Interesting behavior. ) [14:59] fwereade: yeah, i guess so. [14:59] fwereade: i'm just trying to reproduce the behaviour [15:08] fwereade: i can't seem to reproduce the behaviour, which is a bit off [15:08] odd [15:09] rogpeppe, huh, weird [15:09] TheMue, can you repro? you're in my timezone I think [15:09] fwereade: i tried using a time which i parsed from your timestamp [15:09] fwereade: Will try. [15:10] fwereade: could you try this: where the test calls time.Now(), could you make it call time.Now().UTC() instead. [15:11] rogpeppe, bingo [15:12] rogpeppe, fixes all 3 [15:12] fwereade: hmm, it shouldn't make a difference [15:12] fwereade: i'll push a fix see if i can fix the underlying Go too [15:13] s/see/and see/ [15:13] rogpeppe, great, thanks, consider it pre-LGTMed if that's all you do :) [15:13] fwereade, rogpeppe: Same error: http://paste.ubuntu.com/1394620/ [15:32] rogpeppe, sorry, I have no reason to still be waiting for your fix, do I? can I merge? [15:33] fwereade: you can and may [15:34] rogpeppe, cheers [15:35] fwereade: i'm trying to understand the problem a little more before i commit a fix. it's weird that i can't reproduce the problem here. [15:40] rogpeppe: Clearing the environment is handled now. But no need to review so far, I'm currently diving into MAAS. Only has been a litle fix to answer your last review. [15:40] TheMue: ok [15:42] * TheMue is stepping out a bit earlier today. Had no lunch due to pre-christmas-dinner with friends. [15:43] TheMue, enjoy [15:44] fwereade: Thanks. [15:58] rogpeppe: Woohay TLS [15:58] rogpeppe: Just reviewed that last one [15:58] niemeyer: thanks! [16:00]