[07:35] wrtp: where are you ? [07:35] come to the big cloud room [07:35] in the cloud room with the others [07:35] davecheney: ok [07:35] davecheney: what's up? [07:35] reviewing hte hundreds of bugs in py juju [07:36] will be over in a mo, if i can work out which is the "big cloud room" :-) [07:42] fwereade: [07:42] """ [07:42] When jujud has already opened the log file, and then panics, we just [07:42] lose the panic output. So I think we do need this... [07:42] """ [07:42] fwereade: Why would we lose? That's not what append does, AFAIK [07:42] niemeyer, I just checked, and the output is nowhere to be seen -- and that fits with my intuition, that 2 things should probably not open the same file for writing [07:43] niemeyer, am I being stupid? [07:43] fwereade: AFAIK, the reason for O_APPEND in *nix is precisely to handle that [07:44] niemeyer, hum, ok [07:51] niemeyer, I will try to figure out what I got wrong, and get back to you [07:53] fwereade: If it's going to take too long, we can just move forward.. I expected it to be straightforward, though, and it's very handy to not have two files with the same name in the same directory.. we'll always have to type the extension otherwise [07:53] niemeyer, well, I did submit already, but I will see if I can figure out what I did wrong all the same :) [08:21] niemeyer, (ok, I can't figure out what I did wrong, but I clearly did -- using the same file works perfectly... sorry) [09:31] agent_test.go:294: c.Assert(string(data), Not(Equals), "spurious") [09:31] ... obtained string = "spurious" [09:31] ... expected string = "spurious" [09:31] o_O! [09:32] davecheney: Type [09:32] davecheney: Hmm.. whhaaa [09:32] davecheney: Oh, [09:32] davecheney: Not(Equals) [09:34] fair enough [09:34] that is a bit unhelpful [09:34] i'll fix it [09:55] wrtp: GOMAXPROCS=81 go test .../cmd/jujud will fail with an auth error very reliably for me [09:59] bootstrap_test.go:129: c.Assert(err, Equals, expectErr) [09:59] ... obtained = nil [09:59] ... expected *errors.errorString = &errors.errorString{s:"unauthorized access"} ("unauthorized access") [10:00] wrtp: http://paste.ubuntu.com/1304534/ [10:46] wrtp: https://codereview.appspot.com/6767053 [10:46] looking good in stress testing [10:46] cool [10:52] wrtp: now looking at https://bugs.launchpad.net/juju-core/+bug/1064142 [10:58] davecheney, thank you, I've peered at that a couple of times and been totally unable to figure out what was actually happening in the ackground [10:59] fwereade: np, i'll come an nag you if I am confused [12:16] mramm, s/Availability/Available/ [12:24] mramm, s/principle/principal/ [12:24] fwereade: +1 [12:25] mramm, I don't appear to have edit rights, that's the only reason I'm hassling you [12:27] fwereade: please share the link to the google doc. [12:28] Aram, https://docs.google.com/a/canonical.com/document/d/1cm_JDMmk-uA15nSUf5Wz8icbBb4AmCOB-hoJZUfcgsE/edit# [12:28] thanks [13:38] davecheney, where did you guys go, and should I be there? [13:42] most people went to carbo load [14:12] fwereade: https://bugs.launchpad.net/juju-core/+bug/1071320 [14:12] ^ has been happening for a while [14:12] i am investigating now [14:12] (manly as I have no idea how to fix the previous issue) [14:13] davecheney, that aaaaaaaaaaaaaaaaaaa one? I hopefully assigned it to rogpeppe this morning [14:13] davecheney, interesting to see the panic on reset though [14:13] yeah, that is common for most of our tear down tests [14:13] it's not a concern [14:13] davecheney, ah, ok [14:14] davecheney, so the panics come after the failures in aram's problem? and are therefore not a cause of it? [14:19] yes [14:21] davecheney, ty, that is good to know [15:12] fwereade: https://codereview.appspot.com/6781043 [15:12] ^ possible fix for aaa race [15:32] davecheney, I don't understand how https://codereview.appspot.com/6781043 works... but then I don't think I understood the original failure either :/ [15:32] davecheney, rogpeppe may be a better reviewer... [15:50] fwereade: i belive that the hook is exiting before we even start the logger [15:50] but I am trying to understand that bad fd error better [15:50] logically thre is a chance logger.stop could be called before logger.run is scheduled [15:51] or the process could complete and exit before logger.run is scheduled [15:51] davecheney, ah, ok [15:52] the key in that proposal is it mitigates the problem [15:52] doesn't fix it [15:53] but mititgates it to a point that I was only able to reproduce the issue very infreqently [15:53] at which case other failures are taking precidence