[02:17] Bug #1527020 opened: cannot build trusty ppc64el juju

[02:46] wallyworld: I know you're sprinting but any chance you could have a quick look at this one: http://reviews.vapour.ws/r/3404/ [03:02] menn0: sure, looking [03:03] wallyworld: thank you [03:03] wallyworld: sorry to bug you at the sprint. there's not many ppl around today. [03:04] all good [03:09] menn0: lgtm, seems mechanical, justa question about what closes st now [03:13] wallyworld: it's closed by the caller [03:13] rightio [03:13] wallyworld: it probably should never have been closed there [03:17] wallyworld: just read the actual comment, rather than assuming I knew what you were talking about. that's a different thing. just replied. [03:18] wallyworld: thanks for the review [03:18] sure, np [04:02] * natefinch picks up the horse and gives it one more kick for good measure. [04:03] natefinch: ?? [04:03] perrito666: see email [04:04] uh, flamewar, nice [04:04] btw, found the hat? [04:04] no.. I'm going to call the hotel again tomorrow... but I think it's probably just gone. boo. [04:05] natefinch: I would say plane or train? [04:06] perrito666: possibly plane, though I know I didn't wear it that day, it might have been sitting in my coat pocket the whole time, only to fall out when I used the coat as a pillow on the plane. [04:51] axw: wallyworld could any of you take a look at http://reviews.vapour.ws/r/3392/ ? [04:55] dammit gofmt is sad [04:58] stupidest reason for a CI build to fail :/ [05:00] natefinch: you are insensible man, why dont you care about gofmt feelings? [05:01] the fix is deterministic.... the CI bot should just fix it for me. [06:03] urulama: final branch to enable add resources will land soon, maybe a couple of hours, still making a few changes before landing [06:03] cool! [06:21] Bug #1527068 opened: maas 1.8 static ips not released

[06:27] Did someone say earlier that joyent was unhappy? [07:17] blahdeblah: our internal cloud health checks seem to say that Joyent is Green (it had 1 red overnight) [07:17] hmmm.... maybe I'm reading the chart wrong [07:18] it looks like today is on the left, and time goes backwards to the right [07:18] so Joyent has been on-and-off lately [07:19] wwitzel3: katco: ericsnow: (natefinch) I have a question about the recent "create juju upload command" patch if anyone is around [07:28] jam: Thanks; looks like it might be one particular instance; I've contacted support about it [08:23] wallyworld: hey, how is it going? [08:24] frankban: living the dream. finishing final branch to enable add-relation to work [08:24] will land soon [08:24] wallyworld: \o/ [08:24] :D [08:24] final tests to fix, then :shipit: [08:25] great [09:33] frobware, ping [09:34] frobware, your 2 PRs look almost the same - did you mean to close the earlier one? [09:54] dimitern, nope [09:55] dimitern, I'll resubmit the second once the first has landed as it is dependent on the first and might need some agreement on where we put the file [10:00] frobware, I see, ok [10:39] dooferlad: dimitern: frobware: so now all unit tests pass, except one lxdclient test that also fails for me on upstream/master [10:39] dooferlad: dimitern: frobware: I'll create a PR to land my branch on maas-spaces and then do fixes/tests as a new PR [10:39] dooferlad: dimitern: frobware: ok? [10:40] voidspace, sounds good to me [10:40] ok [10:40] voidspace: +1 [10:40] voidspace, dooferlad, dimitern: http://reviews.vapour.ws/r/3398/ [10:40] dimitern, if you could do some verification against your VLAN setup that would be great [10:40] frobware, looking [10:41] voidspace, sorry I missed your question earlier - that sgtm [10:42] great === akhavr1 is now known as akhavr [10:48] axw: i had to add an option to alias the offered service (on the todo list but needed now to support testing in a single env) [10:49] changes pushed [10:49] issue showed up in feature test [10:49] dimitern: frobware: dooferlad: http://reviews.vapour.ws/r/3409/ [10:51] wallyworld: okey dokey, looking [10:51] voidspace, looking in a bit [10:51] dimitern: don't look too closely... [10:53] voidspace, looking [10:57] voidspace, why did you need to embed *common.EnvironWatcher ? [10:57] dimitern: to have access to the environ [10:57] dimitern: we get it through the environwatcher [10:57] dimitern: which means the api/apiserver need access to EnvironConfig api methods [10:58] voidspace, from the client-side api proxy? [10:58] dimitern: that's api/common [10:58] voidspace, in the apiserver side you have *state.State, so you can call EnvironConfig [10:58] dimitern: it's the api side of that interface [10:58] wallyworld, reviewed [10:58] voidspace, I don't think we need EnvironWatcher anymore [10:59] dimitern: the environwatcher waits for the environ to be available and keeps it updated [10:59] dimitern: it calls state.EnvironConfig [10:59] dimitern: on the apiserver using EnvironWatcher exposes the api methods needed by the api side [11:00] voidspace, I know what it used to do :) but the need to wait is long gone - there's always an environ config to read [11:00] dimitern: so if we didn't use it I'd need to manually expose those methods [11:00] dimitern: we want the provider in the worker, so we still need access to the EnvironConfig [11:00] dimitern: so I can manually add that api method to the client and server if that's a better approach [11:00] I'll add an XXX for that [11:01] voidspace, I'd suggest the simpler approach like we used for the addresser [11:01] dimitern: the addresser doesn't use the provider [11:01] voidspace, ok to do it later - will add comments; basically if you expose SupportsDiscovery or something on the apiserver.DiscoverSpaces facade you don't need EnvironWatcher at all [11:01] it delegates everything to the apiserver [11:02] dimitern: we also need to list the spaces and subnets from the provider [11:02] dimitern: in the discussion before we started this we said that the worker would have access to the provider and use the api for the state calls [11:03] dimitern: so we can move provider access to the apiserver, it's just not the approach we decided at the start [11:03] voidspace, yeah, ok [11:03] voidspace, we'll iterate on that later [11:07] voidspace, reviewed; on to frobware's now [11:10] dimitern: thanks [11:30] wallyworld, are you still going downstairs for hangout? [11:30] yep [11:31] ok, will come down soonish [11:33] dimitern, dooferlad, voidspace, mpontillo: Chrome Version 47.0.2526.106 seems to work in MAAS today - I apt-get updated and got <- version and it behaves differently (correctly!) for the dropdowns. [11:34] yay [11:38] voidspace, auto discovered space from your branch: http://pastebin.ubuntu.com/14072670/ whoop whoop! \o/ [11:41] frobware: great! [11:58] voidspace, the unit test failure you mentioned - is this it? http://pastebin.ubuntu.com/14072770/ [12:02] frobware: no [12:02] frobware: mine isn't a panic [12:02] frobware: it's in a lxdclient test, lxcbr0 not found [12:02] hmm... I wonder if I even have lxc installed... [12:03] I do [12:03] voidspace, my build was with go1.2. Just trying again with 1.4.2 [12:04] frobware: with 1.2 you won't get the lxd stuff anyway [12:05] voidspace, sure, but more concerned about the panic now [12:07] frobware: right [12:08] frobware: heh [12:08] looking to see what test that is [12:08] frobware: is that my branch? [12:09] the panic is in imagmetadata, so I assume it's a test for that - I can't specifically see the test though [12:09] make sure you have done a godeps invocation, sure you have but that *could* be the cause [12:10] voidspace, my rebuild-juju alias always does go deps [12:10] voidspace, same panic with 1.4.2 [12:10] frobware: which branch is this? [12:11] voidspace, maas-spaces-networking-api3 [12:11] frobware: weird [12:11] frobware: and which test is it? [12:11] voidspace, yup [12:12] nil pointer dereferences can usually be resolved [12:38] dimitern: frobware: I've fixed the import order issues and added a TODO for getting rid of EnvironWatcher [12:38] I'm going to hit $$merge$$ [12:39] frobware: we'll see if it panics for CI [12:39] it doesn't panic for me [12:39] ack [12:42] voidspace, cheers [12:44] voidspace, so maas-spaces passes for me [12:45] frobware: ah, cool [12:45] spurious then [12:45] voidspace, no... your branch does. :) [12:45] frobware: oh, damn [12:45] other way round... [12:45] frobware: what test is it that panics? [12:46] voidspace, bah humbug [12:46] (asking again as the first two times the question got lost... ;-) [12:46] voidspace http://pastebin.ubuntu.com/14073072/ [12:47] voidspace, just checking again. [12:47] frobware: that doesn't show the test [12:47] I don't think [12:47] there are no test files in that part of the panic [12:47] voidspace, I'm testing in .../cmd/jujud [12:49] so one of the sub-packages there [12:50] ah, I get a panic running it on its own [12:50] I didn't in a full test run [12:51] not sure yet if its the *same* panic [12:51] in cmd/jujud/agent [12:53] frobware: yep, looks the same [12:53] I'm looking into it [12:53] voidspace, thanks. the test seems to take an entirety for me. just .../cmd/jujud/agent [12:54] voidspace, so you don't see that testing with `make check`/ [12:54] I don't do make check [12:54] I do go test ./... [12:59] frobware: looks like this is the test TestNewEnvironmentStartsNewWorkers in machine_test.go [12:59] I'm on it anyway [13:01] voidspace, I see it with go test ./... Weird. [13:01] voidspace, and make check [13:01] frobware: the panic happens in a weird place, don't understand yet [13:01] there is a discoverspaces worker, but the panic is opening the environ [13:01] using the dummy environ [13:02] ah, I have an idea. [13:02] frobware: I've changed the dummy provider to return false for SupportsSpaceDiscovery [13:02] when I come to write worker tests I'll make that configurable [13:03] but for the general case it should be false [13:03] I bet that was the problem [13:03] although it showed up in a weird place [13:03] we'll see anyway - running the test now [13:04] nope, still panics [13:04] there's something not configured right [13:04] * frobware steps out for some lunch [13:32] dimitern: frobware: ping [13:46] no dooferlad today? [13:46] jam: pong [13:47] mgz, was around earlier [13:47] hi frobware, I'm chatting about networks with Mark, and he was hoping for some updates to where we're at [13:47] mgz: I am here... [13:47] do you have 10 min to join us? [13:47] sure [13:47] frobware: https://plus.google.com/hangouts/_/canonical.com/juju-core-spec [13:48] dooferlad: ah, you were quiet. did you need some changes to provider/maas to go with your gomaasapi changes? [13:48] I get some test failures if I bump the dep [13:49] mgz: yea, voidspace made some changes to that bit of code. [13:49] mgz: I didn't intentionally break anything though. [13:50] can I cherrypick that to master? 's on maas-spaces I guess? [13:51] I guess so. I am not particularly familiar with what needs to come across. [13:51] * dooferlad will be back in 5 [13:53] urulama: frankban_ : sorry about delay. code landed. this should work: juju deploy wordpress && juju deploy mysql && juju offer mysql local:/u/me/hosted-mysql && juju add-relation wordpress local:/u/me/hosted-mysql [13:53] not fully tested live [13:54] wallyworld: cool [13:54] wallyworld: I'll test it now, thanks! [13:54] frankban_: i might be asleep, but ping back if there's an issue. should be easy to resolve anything [13:55] wallyworld: sure, go relax and good night [13:55] frankban_: local url optional but needed in this case due to single environment. the service name in url needs to be different to locallly deployed mysql service name [13:55] so there's no name clash [13:56] ack [13:57] will work on proper multi-env support for initial deploy maybe tomorrow [14:01] dimitern: I need some help with testing this uniter stuff when you have a moment. [14:23] Bug # changed: 1524906, 1524914, 1524915, 1524958, 1526003 [14:26] Bug # opened: 1524906, 1524914, 1524915, 1524958, 1526003 [14:32] Bug # changed: 1524906, 1524914, 1524915, 1524958, 1526003 [14:35] Bug # opened: 1524906, 1524914, 1524915, 1524958, 1526003 [14:38] Bug # changed: 1524906, 1524914, 1524915, 1524958, 1526003 [14:39] dooferlad, hey, sorry got distracted with testing - sure, HO? [14:39] yep [14:40] dooferlad, I'll join the standup one in 2m [14:40] dimitern: sounds good [14:42] dooferlad, i'm in [15:04] ericsnow, wwitzel3: did I miss the shortest standup ever? [15:15] dimitern, did you find any issues with the bridge script? [15:34] voidspace, did you find out what the issues was? [15:42] natefinch: moonstone [15:42] frobware: not yet, more logging [15:42] frobware: seems like an impossible bug (uninitialised member of Config struct) [15:43] :qa [15:43] damn, wrong window [15:51] frobware: found it [15:51] frobware: that test uses an environment that needs to explicitly setup singular workers [15:52] so I needed to add the discoverspaces worker to a list of workers to start [15:52] frobware: pushing now [15:52] voidspace, great. but there's a queue forming. :) [15:53] hah [15:56] review please, blue team: http://reviews.vapour.ws/r/3413 [16:04] Could I also get a review? http://reviews.vapour.ws/r/3399/ [16:04] small change, will enable us to actually test controller-rename :) [16:06] cherylj: swapsies [16:07] mgz :) Is there a reason you added in the "SetVersionJSON" calls in environ_whitebox_test.go? [16:08] cherylj: I think I added those [16:08] cherylj: the new default in gomaasapi included stuff we didn't want on by default [16:08] cherylj: see the second commit message, the tests assume a lack of devices support in the maas test server [16:09] and the latest rev of gomaasapi which gets pulled in with this move adds that capability flag [16:10] mgz: ah, you're cherrypicking my changes [16:10] voidspace: I actually reinvented, there wasn't a clear commit to pick === bruno is now known as Guest30927 === Guest30927 is now known as BrunoR [16:17] mgz, does the commit in dependencies.tsv need to be the commit of the merge? [16:18] ex: f342599c61c3303e707660701430297f229cdf6c, rather than what you have? [16:18] (I've always done it that way and I don't know if it makes a difference) [16:19] cherylj: technically no, but it should be, I'll change that === mgz is now known as mgz_ [16:23] voidspace, dooferlad, dimitern: http://reviews.vapour.ws/r/3414/ [16:26] I pushed a new charm to launchpad about an hour ago, it shows up in 'charm list' but juju deploy cs:~my-lp-user/trusty/ yields only an 'cannot resolve charm url' error [16:28] frobware: looking [16:29] BrunoR: it can take a few hours for the charm to show up in the charm store. This is a limitation of the current architecture, but one that we have fixes for already in the pipeline. [16:29] natefinch: ping [16:29] voidspace: yo [16:30] natefinch: it seems to me (you may disagree) that several of your recent emails to juju-core would have been better on the public list [16:30] natefinch: any reason to keep them private? [16:30] voidspace: I was trying to keep them limited in audience to avoid bikeshedding, and because they dealt with coding standards that may not apply to other teams. [16:31] voidspace: I almost sent the last one to juju-dev.... [16:31] natefinch: ok, thanks [16:31] natefinch: I couldn't see anything that needed to be private, and I think "public by default" is a better policy [16:32] voidspace: I wasn't trying to be private, I was trying to avoid starting a flamewar with people who aren't actually on the team [16:32] natefinch: heh :-) [16:32] none of seemed particularly inflammatory [16:32] natefinch: I worry that we'll drift into private by default [16:33] natefinch: before we had that list I think you'd have been happy sending them to juju-dev, which is probably a good test [16:33] voidspace: happy is a strong word [16:33] natefinch: you're a happy person :-) [16:34] voidspace: as for not being inflammatory, I think you underestimate the average developers' capacity to argue about coding standards :) [16:36] natefinch: juju-dev is hardly a hotbed for that, but I stand to be proven wrong... [16:36] I'm sure I will be [16:39] frobware: LGTM [17:05] dooferlad: frobware: dimitern: my branch has landed [17:05] voidspace: Yay! [17:05] voidspace, thedac is going to try it later; will see if it discovers his lab. ;) [17:05] dooferlad: so maas-spaces is now *officially* screwed with untested code and TODOs... \o/ [17:05] frobware: cool! [17:06] frobware: there's lots of reasons why it might not work, but they should *all* be easy fixes [17:06] should work though [17:06] the happy path is pretty good [17:06] voidspace, I think it's important we plant a stick in the ground [17:06] voidspace, awesome! [17:06] frobware: cool [17:07] voidspace, and more of that screwy stuff is coming [17:07] :) [17:08] * dimitern steps out for ~30m [17:09] dooferlad: are you off tomorrow? I don't recall [17:09] voidspace: yes [17:09] dooferlad: enjoy your break! [17:09] see you on the other side [17:10] voidspace: thanks! Have a great Christmas! [17:13] ericsnow: btw, the juju upload PR did land [17:13] natefinch: sweet === benji is now known as Guest79978 [17:26] Bug #1522948 changed: ensure-availability on rackspace spawns endless machines

[17:45] frobware, pig [17:45] ping :) sorry [17:47] dimitern: how rude :P [17:48] frobware, I'm testing your script - it appears to work, however I'm hitting the 15 character limit on the device name - instead of "juju-br-eth0.250" I get "juju-br-eth0.25" [17:48] mgz, hey there [17:48] mgz, you know moving gomaasapi now wasn't a great idea :P [17:48] mgz, was it necessary for something else? [17:53] dimitern: I did mention this last week. [17:53] dimitern: I really don't mind where it lives, thought the long term cunning plan was to redo it entirely [17:55] mgz, yeah, it's better on github, just doing it now introduced some churn with our maas-spaces feature and today I've seen import paths have changed (e.g. more merging to resolve) [17:55] dimitern, ooh. that could be really bad. [17:56] frobware, yeah - the others worked though - no noticeable delay [17:56] dimitern, great. but if you had vlans 25 and 250 that would be bad, no? [17:58] dimitern, I can follow up with making the prefix 'br-' [17:58] frobware, I guess a simple "juju-" vs "juju-br-" prefix will give us enough space up to "juju-eth0.4094" [17:58] frobware, or even "br-" yeah [17:59] dimitern, we can annotate /e/n/i with a comment to say '# rendered by add-juju-bridge' [17:59] dimitern, maybe that could be our sentinel. [18:00] dimitern, if we didn't want to remove the script after it has run [18:00] frobware, oh definitely [18:00] frobware, I'd say "rendered by github.com/juju/juju/provider/maas/add-juju-bridge.py" ? [18:01] dimitern, so I have the run-once-only change up for review: http://reviews.vapour.ws/r/3414/ [18:01] dimitern, I can work those changes in there now. It just depends on how critical this is vis-a-vis getting it laced through to the LXC configs [18:01] frobware, or something like that; also I'll do a quick test now using "juju-" instead of "juju-br-" while reviewing your code [18:03] frobware, also: scrolling up the console I can still see the full script being dumped [18:03] dimitern, that change hasn't landed. it is that review ^ [18:04] dimitern, unless you've pulled that branch explicitly... ? [18:04] frobware, nope, I saw that on maas-spaces tip [18:04] dimitern, maas-spaces doesn't have that change. i did it separately. [18:05] frobware, I guess it's due to cloudcfg.AddScripts("set -xe", runcmd) we do in newCloudiintConfig [18:05] dimitern, you need this http://reviews.vapour.ws/r/3414/ in addition to the tip of maas-spaces [18:06] dimitern, that PR -- which hides the output -- is the review [18:06] frobware, ok, I'll try "juju-" on 3414 then [18:06] dimitern, ack [18:07] dimitern, or 'br-' [18:07] dimitern, cut our losses as 'bond123' will probably blow it at some point. ;) [18:07] dimitern, or should that be bond007 [18:08] :) [18:08] you can't have it all in 2 weeks hehe [18:08] Bug #1527349 opened: Restoration of a backup will fail when moving to 2.0-alpha1 [18:11] Bug #1527349 changed: Restoration of a backup will fail when moving to 2.0-alpha1 [18:24] Bug #1527349 opened: Restoration of a backup will fail when moving to 2.0-alpha1 [18:28] frobware, reviewed [18:29] dimitern, ty [18:31] dimitern, becoming complicated? It's gone from a couple of lines of sed to ... ? [18:33] frobware, what's that? [18:33] dimitern, I was just chuckling at one of your comments [18:33] frobware, ah, well - I mean there's now a makefile, etc. [18:33] dimitern, becoming its own monster. [18:35] :) [18:36] frobware, btw the test worked with "juju-" - http://paste.ubuntu.com/14076709/ [18:36] dimitern, bridge-hydra is what I should have called it [18:36] :D [18:36] dimitern, one thing I discovered this wee is 'ip -d' -- try it as 'ip -d link show up' [18:37] dimitern, shows you kind of dev. ie., tun, bridge, vlan, etc. [18:37] frobware, interesting - a bit more readable even [18:38] dimitern, I hesitated at putting that in because I couldn't see the option in the man page and wasn't sure how well it worked across all series. [18:39] dimitern, presumably the script output went away from your node boostrap [18:40] frobware, yeah it did [18:40] frobware, however, I've just realized spaces weren't discovered [18:40] dimitern, :( [18:41] frobware, it your branch before voidspace's change have landed? [18:42] dimitern, discovery is at the tip of maas-spaces [18:45] frobware, yeah, I'm trying to figure out why [18:46] dimitern, you mentioned something earlier today about 'disable... :true' because of vlans / bridge? Am I recalling this correctly? [18:46] frobware, git log shows your maas-spaces is behind the main repo [18:48] dimitern, my github branch - not in use [18:49] dimitern, I need to clean up. [18:49] dimitern, though I left that there because of the rebase troubles. [18:54] frobware, well, please double check if you need a fresh fetch from upstream maas-spaces tip and rebase [18:56] frobware, as the parent of the tip of your branch's commit is the one before voidspace's last one [19:06] dimitern, ah, yes. for that branch I know because I pushed it last night. [19:07] frobware, ok :) I got worried for a moment [19:07] dimitern, the branch you're talking about is "maas-spaces-add-bridge-script-using-AddBootTextFile" not in fact "maas-spaces", correct? [19:15] frobware, yeah [19:15] dimitern, you had me worried [19:24] okay, it's third-beer-o'clock, which is a very good time to leave irc [19:37] g'night all [20:02] dimitern, frobware: Firstly, go to bed. Secondly, http://reviews.vapour.ws/r/3415/ is the NetworkConfig API call for your review. [20:03] dooferlad: so.... you're telling them to go to bed, but then asking them to review your code? :) [20:03] natefinch: just trying to encourage a healty attitude to it being the evening while blowing my own trumpet. [20:03] dooferlad: haha, fair enough [20:06] dooferlad, great, thanks! [20:06] dooferlad, Can't. I'm in bed. :-p [20:28] ericsnow: reviewing your resources in state patch [20:28] natefinch: thanks [20:51] Bug #1525531 changed: precise upgrades fail in 1.25 and master