[00:20] Bug #1518793 opened: cinder (liberty) fails to retrieve volume limit in Horizon [00:26] does anyone have the link to the build tashboard [00:26] i'm looking for the failing race builder [00:36] menn0_: thumper https://github.com/juju/testing/pull/84 [01:09] WTH? [01:10] fresh build of juju 1.22.7 [01:10] $ juju bootstrap [01:10] Bootstrap failed, cleaning up the environment. [01:10] ERROR there was an issue examining the environment: dial tcp 127.0.0.1:37019: getsockopt: connection refused [01:10] with local provider [01:11] oh ffs [01:12] fuck fuck fuckity fuck [01:12] something changed no doubt with go 1.5 === Spads_ is now known as Spads [01:22] davecheney: why skip tests that fail the race detector? they're failing due to things other than races? too slow? [01:22] thumper: yes, that's fixed on master [01:23] thumper: different error type [01:23] yeah [01:23] patched my local [01:26] axw: because we want go get the race test voting [01:26] then expand [01:27] otherwise people keep committing races [01:27] fair enough [01:29] axw: the tests timeout [01:29] some horrid timing issue [01:29] so, skip them for now [01:29] get the race test voting [01:29] and iterate from there [01:29] davecheney: nps. getting it voting sounds good [02:02] Bug #1518806 opened: apiserver: tests to not pass with -race under Go 1.2 [02:02] Bug #1518807 opened: apiserver/client: tests to not pass with -race under Go 1.2 [02:02] Bug #1518809 opened: apiserver/uniter: tests to not pass with -race under Go 1.2 [02:14] Bug #1518810 opened: cmd/juju/commands: tests do not pass with -race under Go 1.2 [02:17] Bug #1518810 changed: cmd/juju/commands: tests do not pass with -race under Go 1.2 [02:25] wallyworld: thanks for shipit. I may end up changing the watcher as discussed as the worker evolves to support watching the remote side. we'll see. [02:26] axw: yep, np. it's always hard to get this 100% up front. i'm all for iterating on a feature branch and correcting issues as we get futher into the implementtion [02:26] at least we're considering all the options [02:32] Bug #1518810 opened: cmd/juju/commands: tests do not pass with -race under Go 1.2 [03:26] Bug #1518820 opened: environs/bootstrap: tests to not pass with -race under Go 1.2 [03:27] hmm... [03:28] I thought that the lxd provider had been merged into master [03:29] Bug #1518820 changed: environs/bootstrap: tests to not pass with -race under Go 1.2 [03:30] thumper: it has [03:30] i've raised some bugs because now the tests don't pass unless you have lxd installed [03:30] yeah... but I can't bootstrap and NFI why [03:30] and not pass in an impolite way [03:32] Bug #1518820 opened: environs/bootstrap: tests to not pass with -race under Go 1.2 [04:00] thumper: I think there were some build flag restrictions with lxd where it wouldn't work unless you had go 1.3 or later. [04:01] I have go 1.5 [04:01] ah, n/m then :) [04:09] wallyworld: axw: I *think* list cli is ready for review (http://reviews.vapour.ws/r/3171/) [04:09] plz b genetle - i have a hole week ahead of me :P [04:09] anastasiamac: okey dokey, looking [04:09] gentle even [04:09] a "hole" week. what type of hole? [04:10] a big and balck one :D [04:10] black* [04:11] for crying out \o/ [04:11] O_o [04:12] neato. I got my provisioning updater to use the new MAAS 1.9 curtin status: http://paste.ubuntu.com/13469033/ [04:12] thumper: ^^ [04:13] cherylj: sweet! [04:13] I feel better about demoing this now that we can use the new MAAS stuff [04:13] * thumper looks [04:13] cherylj: looking forward to being able to tell what's going on ;) [04:13] thanks axw :) [04:13] nice [04:13] although, the stuff from MAAS isn't as verbose or informative as I was hoping [04:14] yeah that particular message isn't great [04:15] anastasiamac: still reviewing, but please rename "type ListEndpointsServicesResult" to "type ListEndpointsServiceResults" [04:15] anastasiamac: it's a collection of results where each result is a ListEndpointsServiceResult [04:16] axw: there are several result collections [04:16] anastasiamac: this one is in model/crossmodel [04:16] not sure if there are others that need changing yet [04:18] axw: yes.... ListEndpointsServiceResult is "service" and "ListEndpointsServicesResult" is "services" result. The 2nd being really a result from a "service directory" but we did not want to use "service directory" :D [04:19] anastasiamac: not following. I'm looking at the definition of ListEndpointsServicesResult, and its contents are an error, and a slice of ListEndpointsServiceResult [04:20] so how is that not ListEndpointsServiceResults? [04:21] axw: it must b too hot in QLD, but isn't ur head spinning form all "Item"(s) and "result"(s)... I wish we had better less awful names (and naming conventions) [04:22] axw: i'll address after school pickup :D [04:22] anastasiamac: I agree it's not great, but we do have a convention and we do need to stick to it or things will be even worse [04:22] anastasiamac: thank you [04:30] axw: i'll look at api pr, in the meantime, coupld you please look at this small one for charmrepo https://github.com/juju/charmrepo/pull/54 [04:32] wallyworld: LGTM [04:32] ty [04:39] Bug #1518793 changed: cinder (liberty) fails to retrieve volume limit in Horizon [04:39] axw: so we have a naming issue. apifacade.WatchRemoteService(service string) should really call apiserver "WatchRemoteServices". but that method name is already used [04:39] wallyworld: in existing facades it's always singular, even if it takes bulk. it's named after the singular argument. [04:40] s/always/predominantly/ [04:40] axw: yeah, i was about to say except in storageprovisioner WatchMachine() [04:40] mybe elsewhere [04:40] wish we were consistent [04:40] ok, i'll ignore it [04:46] axw: lgtm [04:46] wallyworld: thanks [09:21] jam, hey, sorry :/ I had to do an emergency reinstall of the new laptop this morning, after some package yesterday caused mayhem [09:21] dimitern: we had *just* brought up the new laptop [09:21] jam, nice! congrats :) [09:23] * dimitern discovered even with 15.10 it's quite a challenge to get 4K laptop monitor + HD external monitor to work short of forcing the 4K screen to 1920x1080 [09:36] dimitern: wow, really? I thought it was annoying just having the 4k screen. [09:37] dimitern: no scaling per screen I take it [09:38] dooferlad, it's quite good actually, the issue is text is too small, but when scaled by 200% and it looks fine on the 4K screen, the text on the HD screen is also scaled twice :/ I wish unity supported separate scaling factors per display [09:38] dooferlad, nailed it :) [09:39] yea, same problem with a 1200px high screen and a 1440px one. It is great fun moving a window from the "big" one to a small one because you lose the bottom. [09:40] so while it's perfect with 2 screens of the same size (well, and using nvidia drivers, as "Displays" is too dumb to allow the 4K screen to scale to 1920x1080 - it only shows its native res) [09:41] a full make check takes ~5m now, not 20 [09:41] :-) [09:41] that is about the same speed as my desktop! Nice! [09:41] yeah - quad core i7 + k2100m gpu [09:42] the latter I only tried with steam :) [09:42] :-) [09:43] I'll be living the dream - running tests *while* using a HO at full quality :D [09:59] dimitern: https://github.com/juju/juju/pull/3788 [09:59] voidspace, will have a look [09:59] dimitern: if we want to rebase a feature branch, instead of merge, then we can't just do it as a rebase then merge [09:59] dimitern: because that ends up being the same as a merge [09:59] dimitern: but if we want CI tests run then we *have* to do it as a merge [10:01] fwereade: standup? [10:28] dooferlad dimitern: I *think* the rebase is now done on the feature branch [10:29] voidspace, I'll update and do a make check locally [10:30] voidspace, has it landed? [10:31] dimitern: I pushed... [10:31] voidspace, I can't see any changes [10:31] dimitern: hmmm... [10:32] I pushed to upstream/maas-spaces [10:32] I wonder where that went [10:32] voidspace, it looks like you pushed voidspace/juju branch maas-spaces-rebase-1 [10:32] dimitern: I already had that [10:32] voidspace, ah, ok [10:32] dimitern: that was my initial rebase on Friday [10:33] voidspace, we as mere devs no longer have direct commit rights for the upstream repo btw [10:33] I did a fresh fetch --all then checked out upstream/maas-spaces [10:33] then did a rebase [10:33] then pushed [10:33] dimitern: well I did wonder that [10:33] dimitern: I half expected my push to fail [10:33] dimitern: if that is indeed the case then we *can't* do a direct rebase, except using the jujubot credentials or via CI doing a merge [10:33] however the push *appeared* to work [10:34] but the changes aren't there [10:34] yeah [10:34] let's wait for frobware to come back - he has perms [10:34] cool, he can do it :-) [10:42] * frobware back with new shiny keyboard... :) [10:42] frobware, congrats ;) [10:43] dimitern, dooferlad, voidspace, jam: anything to note from the standup? [10:43] frobware, we need your expertise (and perms) to do the rebase of maas-spaces :) [10:43] * frobware is struck by how nice a new keyboard feels... [10:43] frobware: not unless you count dimiter in HD [10:43] oh yeah - new laptop, new cam, etc. [10:43] dimitern, all working? [10:45] frobware, now it is - I had issues mostly around getting the 4K screen to work with my external HD monitor [10:46] frobware, and I somehow managed to mess up the packages yesterday, so this morning it wasn't booting properly and had to reinstall from the usb [10:46] dimitern, eww [10:47] dimitern, voidspace: rebase to master? I see some chat - what's the redux? [10:47] frobware: I pushed, it vanished [10:48] voidspace, you pushed to hard... :) [10:48] frobware: I shouldn't be able to push anyway as mere devs don't have push rights to core repo [10:48] frobware: probably [10:48] frobware: upshot is, you have to do it as you have perms and we don't [10:48] frobware: so we're leaving it to you [10:48] voidspace, and in terms of the rebase we're happy to take whatever is on tip this morning? [10:49] * frobware will rebase, test, then push [10:50] frobware: well, I thought putting through CI (and therefore doing a merge not a rebase) was a good idea [10:51] frobware: however dimitern and dooferlad point out that we need to accept master *anyway* [10:51] so a rebase is fine [10:51] with the slight caveat that master currently has tests that fail for me :-( [10:51] but those are marked as critical and being worked on [10:52] voidspace, shall we choose a different commit for the rebase then? [10:52] frobware: we could just wait [10:54] voidspace, let's do that; do we urgently need something from master today? [10:54] frobware: I don't think so, we just don't want to drift too far out of sync. [11:07] we have a map ordering dependency in a test [11:07] sometimes it passes, sometimes it fails [11:07] TestListAllOkay in payload/persistence/env_test.go [11:14] or a timing issue I guess [11:17] voidspace, that's in maas-spaces, master, somewhere else? [11:19] frobware: well, I'm looking at my branch [11:19] frobware: I bet it's on master too - will check [11:19] frobware: yep, I see it on master too [11:20] frobware: hard to tell if the ordering is significant [11:21] frobware: committed by ericsnow in October [11:21] voidspace, I just had successful unit test run on master; was rebasing maas-spaces [11:23] frobware: it maybe a timing issue, or a wily issue, or something else [11:23] frobware: but that test fails intermittently for me on master [11:23] frobware: are you on wily? [11:24] voidspace, nope - trusty [11:24] right [11:24] voidspace, I see the same error on wily with go 1.5.1 [11:24] dimitern: I'm using go 1.3.3 [11:24] dimitern: so wily is the common factor [11:25] voidspace, yeah, seems so - why 1.3.3 btw? [11:26] dimitern: I built go from source a long while ago [11:26] dimitern: and have seen no compelling reason to change the version I'm using [11:26] dimitern: I easily can [11:27] voidspace, I see [11:27] voidspace, well, 1.5.1 in wily is slightly faster fwiw [11:29] cool [11:29] will switch at some point [11:38] mattyw, do you recall offhand why api/metricsmanager is using the user-facing ClientFacade stuff? [11:51] fwereade, I'm about to go afk for 30 mins, happy to talk when I get back [11:51] mattyw, no rush [11:52] fwereade, looking at it quickly I suspect it's just bad code - it just needs base.FacadeCaller I think, I'll take a look when I get back an fix it [11:53] mattyw, no need, I've speculatively hit it already, just wannted to check I wasn't missing something [12:15] voidspace, dooferlad, dimitern: http://reviews.vapour.ws/r/3206/ [12:16] frobware: but if you merge it as a pull request it will appear as a merge [12:16] frobware, looking [12:16] dimitern, so it needs pushing to upstream/maas-spaces then? [12:17] frobware, LGTM [12:17] frobware, yeah [12:17] frobware, unless CI can pick it up I guess? [12:27] dimitern: frobware: if CI picks it up it will be a merge not a rebase [12:27] if should be pushed to upstream/maas-spaces [12:39] wallyworld: still around by chance? [12:39] a bit [12:39] wallyworld: the series in metadata for core, is that in a feature branch or trunk for 1.26? [12:39] was featyre branch, merged in last week [12:39] bt ony local so far [12:39] still wip [12:39] need to add forced overrides [12:40] also charm store charms [12:40] and subordinates and upgrades [12:40] wallyworld: ok cool, do we have a list of items needed to wrap it up on the local side? urulama is close to the store end and I want to make sure we've got a path that ties it into a nice bow for delibery [12:41] rick_h_: had a chat this morning, we have a cunning plan :) [12:41] there's the spec which defines the overall. there's no done this, need to do that list [12:41] and yes, we did talk about it :-) [12:41] urulama: :) ok [12:43] rick_h_: i've written the outline of events in the email, but having an action plan would be great, yes. we'll work on it with wallyworld and probably include cmars as well [12:44] urulama: ok ty [12:44] action plan for series in metadata? [12:44] urulama: wallyworld just want to make sure we've got all the parts in sync and no blockers on getting this 1.26 along with the publish stuff. [12:45] wallyworld: yes, series. [12:45] wallyworld: a bit bigger, we've got a proof point of making the juju-gui charm one charm, mutliple series, published with the new development channel work, pushed from our CI infrastructure [12:45] ok [12:46] rick_h_: this was a huge undertaking for the 1.26 timeframe, so the work will be ongoing till the deadlines [12:47] wallyworld: understand, just looking ot make sure there's no dead/blocked time so we can make it. Thanks for the heads up that the current work is in master currently. [12:47] sure, np [12:48] rick_h_: i plan on advertising this to feature buddies for beta1 when the local use cases should be pretty much done (with --force options, etc) [12:49] wallyworld: <3 ty [12:49] adding support for charm store charms will not be too much extra from a core perspective after that [12:50] wallyworld: right, I was just nervous it was still in feature branch and curious how much it would take to get it merged into master as sometimes that seems to take a bit. [12:50] wallyworld: my concerns are all put to bed :) you go enjoy your evening. [12:50] rick_h_: it did take a bit, but i've done it already :-) [12:51] rick_h_: if you definition of enjoy is working on a series in metadata PR, I will have a ball [12:51] :D [12:51] that's a small PR, wallyworld :) [12:51] checking if that's all that needs to change, now, that's another thing :P [12:52] i wish it were simple, this current PR has a lot of touch points [14:17] help please bootstrapping agent-version? http://paste.ubuntu.com/13476900/ [14:25] dooferlad: your branch of gomaasapi on launchpad doesn't currently build [14:25] dooferlad: do you have a version you can push that does build? [14:25] voidspace: In the middle of a change, but give me a few minutes [14:25] dooferlad: cool - thanks! Let me know when. [14:25] voidspace: do you have a build error you can pastebin? [14:26] dooferlad: obviously doesn't need to be feature complete but I'd like to start using the bits that do work [14:26] dooferlad: line 101 of testservice.go Space undefined [14:26] dooferlad: the spaces member of the TestServer is map[uint]Space [14:27] voidspace: bother, OK. [14:27] dooferlad: maybe you forgot to add a file? [14:27] voidspace: I purposefully didn't, but clearly I need to. [14:27] heh [14:42] voidspace: give that a go [14:43] voidspace: example code: http://pastebin.ubuntu.com/13477034/ [14:43] dooferlad: "github.com/dooferlad/here" [14:43] voidspace: no tests for the newest code, but I hope it compiles. [14:43] dooferlad: in jsonobject.do [14:43] *.go [14:44] voidspace: Eugh, just delete all here references and you will be fine. [14:44] dooferlad: ok [14:45] here is used quite a lot in testservice.go [14:45] dooferlad: is this because you're developing on github and then pushing to launchpad? [14:45] or some other hack [14:46] or is it an error logging package [14:46] voidspace: it is my debug data logger library. You can go get github.com/dooferlad/here to make it go away [14:46] dooferlad: cool, I'll do that [14:46] voidspace: it is really quite useful for debugging. [14:47] dooferlad: yay, builds! [14:47] dooferlad: and I'll look at your debug logger later :-) [14:47] voidspace: yay for building! [14:47] voidspace: I will brew tea in celebration! [14:47] dooferlad: :-) [14:47] me too I think [14:58] wwitzel3, ping? [15:16] voidspace, dooferlad, so apparently p&c fixed the hr site and I'm no longer your manager there :) [15:17] but cadmin is yet to be fixed, so expense claims still come to me [15:20] dimitern: congratulations on having less admin to do! [15:21] dooferlad, cheers :) [15:38] dimitern: voidspace Do either of you have a minute to review http://reviews.vapour.ws/r/3208/ [15:38] sinzui, LGTM [15:39] thank you dimitern [15:56] voidspace: branch updated [15:57] voidspace: minor change in usage. See TestSubnetsInNodes. [15:59] katco, ping? [16:00] mattyw: she's out this week [16:01] natefinch, yeah I only just saw, I pinged before checking the calendar [16:40] Bug #1519027 opened: lxd cannot bootstrap with streams

[16:55] Bug #1519027 changed: lxd cannot bootstrap with streams

[16:58] Bug #1519027 opened: lxd cannot bootstrap with streams

[17:01] voidspace, dimitern, frobware: hangout [17:01] natefinch, you are the only moonstone rep this week correct? [17:04] alexisb: eric is around more or less this week, but he just moved into a new house over the weekend, so may be in and out. [17:04] alexisb: otherwise, yes [17:13] dooferlad: dammit, always catches me by surprise [17:13] I should check at the start of the day === Spads_ is now known as Spads === Spads_ is now known as Spads [18:16] dooferlad: so subnet IDs come in from the test server as integers - which the gomaasapi helpfully turns into float64 [18:16] dooferlad: as far as I can tell this does match what maas itself spits out [18:16] dooferlad: but it's a mild pain for the code [18:17] dooferlad: currently it doesn't look like the space name is making it across from the test server though (I'm getting nil back from the json even though the gomaasapi.CreateSubnet has the Space field populated) [18:48] ericsnow: one of your payload tests fails intermittently on wily [18:48] ericsnow: maybe a go 1.3+ issue (do you use go 1.2?) [18:48] ericsnow: and new house? [18:49] voidspace: :) [18:49] :) [18:49] voidspace: does it look like #1516541? [18:49] Bug #1516541: payload/api/private: tests do not pass [18:49] ericsnow: no [18:50] voidspace: k, I'll take a look [18:50] ericsnow: payload/persistence [18:50] voidspace: filed a bug? [18:50] ericsnow: of course not [18:50] voidspace: :) [18:50] ericsnow: doing it now [18:51] voidspace: thanks [18:52] ericsnow: https://bugs.launchpad.net/juju-core/+bug/1519061 [18:52] Bug #1519061: payload/persistence intermittent failure [18:52] voidspace: thanks [18:53] ericsnow: dimiter sees it too, I use go 1.3 and he uses go 1.5 [18:53] Bug #1519061 opened: payload/persistence intermittent failure [18:53] ericsnow: we're both on wily [18:53] voidspace: k [18:58] Bug #1519061 changed: payload/persistence intermittent failure [19:01] Bug #1519061 opened: payload/persistence intermittent failure [19:04] Bug #1519061 changed: payload/persistence intermittent failure [19:07] Bug #1519061 opened: payload/persistence intermittent failure [19:08] frobware: ping? [19:13] frobware: if you're still around, could you update bug 1516891 with your status? [19:13] Bug #1516891: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface [19:30] waigani, ping [19:30] fwereade: pong [19:31] waigani, do you know any of the details of how we auth the per-env api connections for the per-env workers? [19:32] waigani, can controller-machine-0 always log into its own hosted environments? or do they have separate creds or something? [19:33] waigani, ("I have no idea" is a perfectly reasonable answer, no need to look stuff up if it's not immediately to mind, I'm just looking for a quick answer if it's there) [19:33] fwereade: right, I was digging :) [19:34] waigani, np, I can dig myself :) [19:34] okay, yeah of the top of my head all I can say is it's a good question. thumper will be on soon. I'll check with him too. [19:35] fwereade: btw I'm polishing off the system kill. Here's the output: http://paste.ubuntu.com/13468747/ [19:35] waigani, that would be nice, thanks [19:36] and with -v : http://paste.ubuntu.com/13468473/ [19:36] nice :D [19:36] lovely [19:36] I'm going to add a header and footer message and not count dead environments [19:36] waigani, yeah, sounds good [19:36] but yeah, it was cool to watch everything go down [19:37]