[00:02] waigani: hi [00:03] wallyworld: could I hangout with you for 5min? [00:03] sure [00:45] nites/morning people [00:46] wallyworld: just swapped two occurrences of GetMockBuildTools for GetMockBundleTools in one file: http://paste.ubuntu.com/7486270/ [00:47] wallyworld: tests now pass [00:47] great [00:48] I'll leave it there for now unless you/william think it is urgent to get rid of GetMockBuildTools all together. [00:48] I need to start looking at identity now [00:55] g'morning [00:55] morning hazmat` [00:55] morning perrito666 === hazmat` is now known as hazmat [01:20] axw: morning, good weekend? [01:21] wallyworld: morning, yeah not too shabby [01:21] never get to rest anymroe on the weekend though [01:21] i had to give my son a driving lesson, very stressful :-) [01:21] ooh :) [01:21] good news on the house? [01:21] mine was slightly stressful too ;) [01:21] yes [01:21] \o/ [01:21] it is ours [01:22] great :-) [01:22] we should have martin back today, so standup tonight [01:23] cool, sounds good [01:23] feel free to ping me before then if required. you've got some wip and i've made a couple of cards high propority [01:23] no worries [01:23] the cards i've bumped are the cause of the last few test failures [01:24] on jenkins [01:24] axw, wallyworld: local tests are getting better, 5 times through only one failure, replicaset [01:24] yeah, getting there :-) [01:24] wallyworld: we need to chat, can I grab you in about 15 minutes? [01:24] sure, anytime [01:24] thumper: glad to hear that [01:24] the peergrouper one was a pain in the arse [01:28] any plans on how to fix the replica set failures? [01:28] they seem problematic [01:30] one fix has gone in already [01:31] to retry after starting mongo since the replicaset may not be ready just yet [01:31] just need to keep plugging away at it, mongo seems quite flakey at times [02:17] just spotted this in trunk: provider/openstack/storage.go:59: assignment count mismatch: 3 = 2 [02:17] anyone on it? [02:24] waigani_: your goose deps are wrong [02:25] oooh [02:26] godeps will fix it [02:26] wallyworld: I just filed a bug. Is there a way to delete it or should I mark it as invalid? [02:26] mark it as invalid [02:27] done [02:54] wallyworld: are our architecture codes meant to match simplestreams? if not, is there a mapping somewhere? [02:55] the codes in arch.go? [02:55] wallyworld: yeah, i386, armhf, etc. [02:55] there's a regexp transformation in arch.go [02:55] NormaliseArch() [02:55] wallyworld: that's for uname [02:55] isn't it? [02:56] yeah, uname [02:56] ah, sorry was going from memory [02:56] wallyworld: I found that the tests in environs/instances use dummy simplestreams data that has an entry for "arm", whereas we expect armhf [02:56] in that case i think the codes are meant to match [02:57] wallyworld: ok, so I will change that dummy data [02:57] yeah, that may well be wrong [02:59] https://bugs.launchpad.net/juju-core/+bug/1320738 [02:59] <_mup_> Bug #1320738: constraints: gccgo test failure

[02:59] bugger [04:18] Gobot reports environs/sync [build failed], but when I run the tests locally it passes... hmmm [04:22] ah, I see why, ignore me [04:50] thumper: are we generally cancelling our weekly 1:1? Did you find a better time? [05:07] I'm hitting this on the gobot: [05:07] PANIC: sync_test.go:420: badBuildSuite.SetUpTest [05:07] ... Panic: cannot share a state between two dummy environs; old "only"; new "only" === vladk|offline is now known as vladk [06:06] https://bugs.launchpad.net/juju-core/+bug/1320738/comments/1 [06:07] <_mup_> Bug #1320738: constraints: gccgo test failure

[06:07] annoying [06:32] thoughts, http://paste.ubuntu.com/7487106/ ? [07:10] axw: did you confirm your mp fixes the tests on i386 by doing a test run, perhaps with version.Current.Arch hardcoded or something? [07:11] wallyworld_: yes that's what I did [07:11] great [07:11] wallyworld_: modified juju/arch/arch.go [07:12] ok [07:13] axw: ultimately i'd like to mature the ToolsFixure and consolidate a lot of the older code [07:13] wallyworld_: sounds good. less reliance on version.Current would be nice [07:14] yep. it's all very messy in that area [07:14] wallyworld_: are you going to look at the prereq too, or leave it for fwereade? [07:14] looking now [07:14] morning all! [07:14] o/ [07:15] hye dimitern [07:15] hey* [07:15] axw: i also want to get rid of the hard coded json metadata cause we have marshalling capability now also [07:16] oh, and don't forget to update the mp covering description of the 2nd branch [07:16] wallyworld_: hm yeah. we could just have an init() function that renders the images/tools objects [07:16] wallyworld_: will do [07:17] we can set up a slice of metadata structs and just marshal those [07:17] much easier than all the json [07:17] yeah, very finicky [07:18] miss a comma and it's all over [07:20] yep, happened to me today [07:20] had to run it through a parser to find the rrror === vladk is now known as vladk|offline === Tribaal_ is now known as Tribaal === vladk|offline is now known as vladk [08:14] morning all [08:26] morning! [08:28] morning [08:29] mgz: good morning [08:35] wallyworld_: I think you're going to have to merge changes for i386 fixes in provider/joyent [08:35] axw: yeah, figured as much when i saw your work :-) [08:52] wallyworld_: any chance we could delay the standup for till quarter past? [08:52] -for [08:52] axw: no problems [08:52] thanks [08:55] fwereade: hiya, will you be free for a chat in say 45 minutes? [08:55] wallyworld_, sure [08:56] awesome, i'll ping you after our standup === axw_ is now known as axw [09:13] wallyworld_ mgz ready when you are [09:17] so is it intentional that virtually all team names (except onyx) are blue stones? [09:17] :) [09:18] i didn't know how moonstone or tanzanite look like, but both are blue and the latter is almost exactly the same color as sapphire [09:37] jam: yes, we need to find a better time... [09:37] dimitern: tanzanite is actually a bit more of a purple, and moonstone is white. [09:38] emerald is more green [09:39] dimitern: we just won, everything is a shade of blue now [09:40] jam, yeah, I forgot about emerald :) [09:40] mgz, exactly ;) [09:40] mgz, welcome back btw [09:42] thanks dimitern :) [09:47] fwereade: you ok for a chat now? [09:48] wallyworld_, yeah [09:49] https://plus.google.com/hangouts/_/g6w7cwvuro6wshqar324ytpg5ma?hl=en [10:31] fwereade: if you're done chatting with wallyworld, I wouldn't mind an ear to bounce a couple more API thoughts off of [10:33] jam, sure [10:33] jam, done chatting with mgz as well :) [10:34] fwereade: https://plus.google.com/hangouts/_/canonical.com/juju-sapphire [10:34] we have our standup in 10m anyway [10:38] mgz: I think I have the instancepoller test under control, will let you know later if I don't think I will get it fixed soon [10:40] axw: ace [10:45] morning everyone [10:46] vladk: dimitern: TheMue: standup ? [10:47] jam: yep, lost the link :D [11:00] fwereade: hi, regarding your comment in https://codereview.appspot.com/92320043/ do you have any objections regarding merging this? [11:09] wallyworld_: have a good evening [11:10] jam: will do, sorry long day today, very tired [11:10] np [11:12] perrito666, I think it's fine to merge [11:12] perrito666, this feels like one of those cases where we really need some sort of docs though [11:13] perrito666, just to make the expected usage and situations and so on clear [11:13] fwereade: yup, we have doc duty too, but I did not want to propose a pull request for the docs before merging the code [11:13] perrito666, one question: does this fail properly when run against an env with a running state server that *isn't* the bootstrap node? [11:14] perrito666, I think we all agreed that docs come first [11:14] perrito666, they don;t need to be *good* but they do need to go to evilnick early so he can massage them into shape [11:14] perrito666, and so that we have some sort of idea what we're actually implementing, too ;) [11:14] fwereade: agreed, specially since this use case is not all that intuitive [11:15] perrito666, cool [11:15] * perrito666 pull requests first [11:16] fwereade: mmm, good question about the node, it fails on non HA, Ill make a test run for that case just to be sure [11:25] perrito666: morning [11:27] axw: ping [11:27] if you're still around [11:36] natefinch: morning [11:36] natefinch: who are you interviewing, anyone interesting? [11:36] dimitern: did you want to talk about addressible containers with vladk ? [11:36] voidspace: Not particularly... seems an ok candidate [11:36] natefinch: cool [11:37] natefinch: I'm down a rabbit hole of rsyslog changes (again) [11:37] voidspace: ug [11:37] natefinch: whilst flowing host ports around I discovered one serious bug in our current implementation [11:37] natefinch: previously it was only port/cert that could change - so in the worker handler there's a shortcut that doesn't render/restart if those haven't changed [11:37] voidspace: I'm here atm, but may disappear at a moment's notice [11:38] natefinch: whereas now we can add a new state server without the port or cert changing [11:38] natefinch: that was easy to fix [11:38] axw: are you normally around until about this time? [11:38] axw: I can ping you earlier tomorrow [11:38] voidspace: no, not normally [11:38] ah... [11:38] voidspace: usually clock off about 1h40m ago [11:41] axw: ok, I'm usually on well before then [11:44] natefinch: fwereade: FTR axw says that the rsyslog port and cert are in the environment "at the time the environment is bootstrapped" [11:44] ooh wait [11:44] natefinch: fwereade which means that we are fine to only watch APIHostPorts in the general case [11:45] axw: haha, ok... [11:45] voidspace: I may have brain farted [11:45] axw: would you rather continue this tomorrow - I have plenty of other stuff in the meantime [11:46] jam: FYI - I have to skip our meeting today to get the kids prepped early so I can be ready for the interview in a little over an hour. [11:46] voidspace: probably better, I don't want to keep feeding you lies [11:46] voidspace: I think the rsyslog-ca-cert is actually generated post-bootstrap [11:47] axw: hmm... ok [11:47] that doesn't need to be kept like that though [11:47] was just to consolidate bootstrap/upgrade logic [11:47] axw: you can point me to the code tomorrow [11:48] axw: so long as it is *before* the rsyslog worker is created we're ok, but that may not be the case [11:48] voidspace: it's not, it's created by the rsyslog worker [11:48] voidspace: see "ensureCertificates" in worker/rsyslog/worker.go [11:48] axw: ah, which also doesn't matter then [11:49] it sounds like we're good [11:49] axw: I'll spelunk that code a bit more [11:49] cool [11:50] fwiw I think we could extract that bit out to bootstrap time, and make rsyslog-ca-cert immutable in 1.20 [11:50] ok [11:59] lunch [11:59] voidspace: you have the most random lunch pattern ever [12:03] perrito666: I've got 10 minutes before my next meeting… Lunch! [12:03] perrito666: yup [12:03] perrito666: I *aim* for 1pm (now) - but often miss it by a couple of hours [12:04] natefinch: one thought, the test here: http://juju-ci.vapour.ws:8080/job/local-deploy/1309/console is running on a Precise machine. which *might* be why it would be seeing different results. [12:04] perrito666: although moving our standup to 3pm made that harder [12:04] perrito666: so this sort of time will probably be more normal for me now [12:05] voidspace: good luck then :) [12:38] fwereade: nice spot there, turns out that restore will restore if there are other state-machines as long as machine 0 is dead [12:38] perrito666, cool [12:38] perrito666, well, not cool [12:38] ykwim [12:39] hehe, yep [12:39] perrito666, is it that we're not storing the current set of state servers on the provider now? [12:45] jam: I have to step out for some minutes. there are some open questions in our doc, could you please take a quick look? tia [12:45] fwereade: I think it is the way restore checks if stateservers are up, as long as one is down it will consider that it is safe to restore [13:14] TheMue: I tried to respond to them, there are a few more "comments" in the dropdown box that seem to be related to stuff you've already deleted. [13:32] fwereade, fyi https://bugs.launchpad.net/juju-core/+bug/1314686 is blocking any SRU activity of 1.18.x into trusty right now [13:32] <_mup_> Bug #1314686: Please add support for utopic

[13:34] jamespage: we can't help unless the extra mongo logs are attached as requested so we can see what is going wrong [13:36] wallyworld_, rbasak is just reproducing again to get that [13:36] great, thanks :-) [13:37] we may need to set up a utopic vm to test with [13:37] wallyworld_, sure - we have pubished cloud images on the daily stream for utopic now [13:38] the initial fix was for the core issue with juju which was lack of utopic knoledge [13:38] juju now knows about utopic but i guess mongo is unhappy [13:39] wallyworld_, maybe - I'm just upgrading a server to utopic to repro as well [13:39] ok. i was hoping teaching juju about utopic would be enough [13:40] a new bug may be pertinent as there are 2 separate issues to address [13:40] back again [13:40] jam: thx, will take a look [13:47] is there any way of building all test packages *as well* [13:47] I would like to find compile errors in the tests (I've changed some apis) and "go build ./..." [13:47] omits test packages [13:47] hmmm... maybe it has a flag [13:53] fwereade: you where right [13:53] perrito666, is it that we're not storing the current set of state servers on the provider now? [13:55] perrito666, cool [13:55] fwereade: not really :p [13:55] hehehe [13:56] perrito666, on this occasion, I men it's cool that my psychic debugging skills are still here [13:56] perrito666, and at least there should be a path to fixing that, right? [13:56] yep :) [15:03] natefinch: you still interviewing? [15:04] voidspace: sorry, no, got caught up in writing down my thoughts about it. I'll be right there [15:04] natefinch: cool [15:06] wwitzel3: standup? [15:07] natefinch, perrito666 Hi guys, I've been working on other things today so I'll be taking a look at the ensureavailabilty command tomorrow, just wanted to let you know [15:07] mattyw: cool, no problem [15:07] mattyw: we're doing a standup right now, would you like to join? [15:07] natefinch, I certainly can do [15:08] natefinch, moonstone? [15:08] mattyw: https://plus.google.com/hangouts/_/canonical.com/moonstone?authuser=1 [15:08] yep [15:18] natefinch: this is a diff against Wayne's branch [15:18] https://code.launchpad.net/~mfoord/juju-core/ha-rsyslog-api/+merge/220087 [15:19] natefinch: this is before fixing the old tests that are now broken and adding new tests for the changed behaviour [15:25] natefinch: lines 339-343 of that diff is the removal of the obsolete check (without which the existing CL is broken) [15:42] uff, I just missed dimitern [16:15] I have https://codereview.appspot.com/12841044 and https://codereview.appspot.com/94540043/ up and would appreciate reviews [16:15] yes, that is a 9-month gap between the prereq and the followup :/ [16:16] fwereade: looking [16:20] fwereade: we love you anyway [16:25] huh delete(someMap, keyNotInMap) doesn't have any error-y-ness [16:26] * perrito666 gets scared to death when her wife is followed by a twitter botnet and her tablet, next to him, starts making sounds as if being possessed [16:26] her? is there something you're not telling us? [16:27] mgz: her tablet? [16:27] next to me? [16:28] its interesting what 150 notifications make to android [16:28] "/me gets... when her wife is"... the her has the wife, clearly [16:28] heh [16:41] natefinch: this is the mp for just removing the "dangerous check" (plus a "now obsolete and failing" test) [16:41] https://code.launchpad.net/~mfoord/juju-core/ha-rsyslog-shortcut-removal/+merge/220105 [16:58] voidspace: thanks [16:58] right, off to krav maga [16:58] back shortly [16:59] voidspace: kick some butt [16:59] natefinch: I'll talk to wwitzel3 about that branch [16:59] voidspace: cool [16:59] natefinch: he might as well merge it into his before landing [16:59] heh [16:59] we don't kick butts much [16:59] not an effective place to kick [16:59] groin or the back of the knee [16:59] or the chest if someone is coming towards you [17:00] c'ya later all [17:00] voidspace: and this is why I'm glad you're on my team and not someone else's :) [17:00] * perrito666 is glad you are all 14k of his but, groin and back of knee [17:00] hehe, nice === Ursinha is now known as Ursinha-afk === BradCrittenden is now known as bac [17:47] fwereade: doc/architectural-overview.txt line 118 , care to tell me the end of that tale? :) === Ursinha-afk is now known as Ursinha === vladk is now known as vladk|offline [18:45] dumb bzr question [18:45] if I'm in a cobzr branch and merge in juju-core [18:45] and commit [18:45] and then do go get -u ./... [18:46] should I expect to lose my locally committed changes irretrievably? [18:46] don't use go get when developing on a branch [18:46] yeah... :( [18:46] or rather: don't use go get when developing [18:46] I usually switch to master and do that to get updated dependencies [18:46] you shouldn't ever be able to lose your changes forever [18:47] it's version control, that's what it's for [18:47] natefinch: that's what I would expect [18:47] natefinch: but I can't find the revisions and don't know enough about bzr innards to know where to look [18:48] so, after doing a go get -please-screw-up-my-workspace .... hopefully a simple bzr revert would put you back in the right spot, but I'm not 100% sure [18:48] haha [18:48] sadly bzr status looked happy and I switched to master and back and that's when I noticed my missing revisions [18:49] did you push the changes or just commit locally? [18:49] just local [18:49] if I'd pushed them I'd just blow my local branch away [18:49] :( [18:49] right [18:50] If I'm in a branch and merge in juju-core... and juju-core has new dependencies... how should I retrieve them if not go get -u ./... [18:50] ? [18:50] manually for each import error? [18:51] jcw4: godeps [18:51] so, the proper way to update dependencies in juju is to go to the root directory of juju-core and do godeps -u dependencies.tsv, which will sync all external branches. Occasionally that'll return an error like "abc1234 is not a valid revision on branch foo" which just means that you need to go do a bzr pull on that repo, because dependencies.tsv references a revision that exists on launchpad but not on your local machine [18:51] godeps is what gave me the error [18:51] because I didn't have the new errors package downloaded [18:51] righ [18:51] right [18:52] so; manual get of dependencies in that case... [18:52] sigh. so much to learn [18:52] yeah, it's a failing of godeps [18:52] :) [18:52] tx natefinch perrito666 [18:52] natefinch: jcw4 yep, godeps falls short in a few very common cases :( [18:53] there's two failings - one is repos it's never heard of before, like the errors packages.... that doesn't happen very often since we don't add dependencies very often. The one about revisions not existing locally happens all the time, unfortunately. We should really spend some time fixing it up so it just does the right thing all the time. [18:53] neither of those two problems is really that hard to fix, since the solution is blatantly obvious each time [18:53] If I didn't misunderstand it looks like internal Google teams use godeps too? [18:54] they may use godep .... which has a very similar name, but does very different things [18:54] natefinch: oh. Interesting. Maybe that's what I saw. [18:54] well, they don't use godep, they use something LIKE godep, which they aren't sharing ;) [18:54] teh suk [18:54] ;) [18:55] Yeah, Google doesn't open source enough of their stuff, unfortunately. [18:57] I imagine that that tool would be getting ticklishly close to their competitive advantage in managing vast complex code-base [18:58] probably. They do just have everything in one hugely massive repo.... so all third party code is also in the repo (which means it needs to have its import statements fixed up to point at google's repo and not github or whatever) [18:58] hmmm; the 'vendor' folder approach [19:00] exactly. Honestly, that's the only way to be 100% sure your code will always build. We've avoided that with juju because all our dependencies are really controlled by us, or people who work at the company. So if Gustavo's mgo package suddenly breaks, we can go hound him about it ;) [19:00] dependencies in juju haven't become tedious enough for us to adopt that approach I suppose. right [19:00] fun [19:01] natefinch: No need to change imports for that.. a controlled GOPATH environment would work fine [19:02] niemeyer: yeah, that requires a little more futzing with the local environment, though [19:02] niemeyer: so... using a vendor folder + GOPATH that points to it? [19:02] natefinch: Well, just using a GOPATH with content that is under your control rather than arbitrarily taken from the net [19:03] s/natefinch/jcw4 [19:03] niemeyer: I see. Makes sense [19:03] That's what godeps does, for example [19:03] Erm godep [19:05] ahh, ok, I was mistaken about how godep works, I thought it was rewriting import paths. I know camlistore has a tool they use to do that. It's hard keeping all these tools straight :( [19:05] how exactly does it expect the dependency entry to be formatted? [19:05] e.g., launchpad.net/tomb bzr gustavo@niemeyer.net-20130531003818-70ikdgklbxopn8x4 17 [19:05] I'm not sure what the third and fourth entries are [19:05] or where to look for that info, anyway [19:07] I'd hazard a guess at #3 (timestamp + hash?), but #4 defies even guessing :) [19:08] I think it's specified in CONTRIBUTING [19:08] yep [19:09] line 234 [19:09] tab-separated [19:10] according to godeps source it looks like #3 and #4 are vcs specific [19:10] revid, revno [19:10] godeps -t $(go list launchpad.net/juju-core/...) > dependencies.tsv [19:10] :) [19:11] and a #5 an optional 'clean' flag [19:11] oops optional revno [19:25] hmmm [19:25] this doesn't want to work properly [19:26] natefinch, ping? [19:27] here is but in a meeting [19:27] -ish [19:31] natefinch, I've got my leankit account setup, was trying to find the ensureavailability more logging card on the board [19:32] natefinch, ah, I see it === vladk|offline is now known as vladk === meetingology` is now known as meetingology [20:14] perrito666, there's an orphaned line 20 or so further down [20:14] perrito666, fixed in followup (actually just removed) [20:15] tx === vladk is now known as vladk|offline === vladk|offline is now known as vladk === vladk is now known as vladk|offline === vladk|offline is now known as vladk === vladk is now known as vladk|offline [21:23] morning ppl [21:25] menn0: morning :p [21:35] morning all [21:40] I'm getting this panic from gobot that I can't reproduce locally: http://pastebin.ubuntu.com/7490387 [21:40] Panic: cannot share a state between two dummy environs; old "only"; new "only" (PC=0x414311) [21:46] waigani: poisoned env? [21:47] perrito666: what does that mean? [21:48] The env where that is being run is dirty? [21:50] waigani: you might want to go in there and clean the bot's env by hand [21:51] perrito666: right, I've never done that. [21:51] waigani: neither did I [21:52] i assume Its sshing in and rming go/pkg [21:52] waigani: yup [21:52] but I might wait and check with wallyworld_ (I also don't know where to ssh into) [21:52] wot [21:52] hey :) [21:52] wallyworld_: aha, lurking [21:53] coding :-) [21:53] it's early for you right wallyworld_ ? [21:53] yeah [21:53] not toooo early [21:53]