[00:40] waigani: no real idea what is wrong with your clone [00:40] * thumper goes to make fud [02:05] thumper: do you have the link to the prototype code for the btrfs stuff? === mwhudson is now known as zz_mwhudson === tasdomas` is now known as tasdomas [09:07] * fwereade out for a bit [09:17] dimitern: I'm going to miss the standup today, I have a management training course, can you keep everyone on track? [09:21] jam, sure, no worries [10:16] g'morning [10:48] dimitern: standup [10:48] mgz: ^ [12:22] guys, can someone look at these two bugs (dupes): lxc doesn't work with the maas provider [12:22] https://bugs.launchpad.net/juju-core/+bug/1274210 [12:22] <_mup_> Bug #1274210: Creation of LXC bridge in 1.17.0 fails

[12:22] https://bugs.launchpad.net/juju-core/+bug/1271144 [12:22] <_mup_> Bug #1271144: br0 not brought up by cloud-init script with MAAS provider

[12:22] it's because bridge-utils is installed *after* the bridge is configured and networking is restarted [12:22] so br0 never comes up [12:22] a) configure bridge [12:22] b) restart networking (does nothing useful) [12:23] c) install bridge-utils [12:23] either brigde-utils should be installed before (b), or (b) should happen after (c) [12:23] oh, only happens with the 1.17 series [12:23] 1.16.6 works fine [12:47] ahasenack, bridge utils gets installed early in the 1.17.3 [12:48] hazmat: not in the bootstrap node [12:48] hmm [12:48] hazmat: the above happens in the bootstrap node, for some reason it's provisioned differently [12:49] ahasenack, quite possible.. could you pastebin /var/lib/cloud/instance/user-data.txt [12:49] on the bootstrap node [12:49] I don't have it anymore [12:49] but it's easy to reproduce [12:49] yup [12:49] no worries. [12:50] * hazmat connects to a maas env [12:58] hazmat: I have a bootstrap node on maas almost up, if you're interested [13:03] i've got one [13:03] ahasenack, sure.. re pastebin of its that user-data on the bootstrap node [13:04] hazmat: http://pastebin.ubuntu.com/6994263/ [13:04] ahasenack, oh.. i forgot.. synchronous bootstrap [13:05] hazmat: here is a bootstrap --debug from sparkiegeek: http://paste.ubuntu.com/6994260/ [13:05] cool [13:11] debugged in the other channel.. bridge only setup on nodes using userdata [13:11] which doesn't include the bootstrap node.. for those following along === edamato is now known as edu-afk [13:35] dimitern, thanks for the reviews - I'll take a look at them and see what I can sort out [13:42] well more specifically bridge-utils not installled on bootstrap node till after network create/restart. [13:42] which is basically what you diagnosed ahasenack .. just a circle to find out how. [13:47] mattyw, cheers [15:15] fwereade, ping [15:15] hazmat, pong === allenap_ is now known as allenap [15:53] * fwereade bbiab again [18:47] fwereade, dimitern, natefinch: a review of this would be very much appreciated: https://codereview.appspot.com/68650044 [18:47] * wrtp is done for the day [18:47] wrtp, looking [18:47] wrtp, enjoy your evening [18:47] dimitern: thanks [18:47] fwereade: will do! [18:49] dimitern: there are a couple of drive-by fixes in there that could perhaps be factored out (the testing/mgo.go one prevents a race detector complaint) [18:49] wrtp, ha! i was just wondering just about that [18:50] dimitern: the change in voyeur just makes it more convenient to use [18:50] wrtp, ok istm those are small enough to have them in the same cl [18:51] dimitern: thanks; i thought so, but opinions differ... [18:54] wrtp: looking, too === zz_mwhudson is now known as mwhudson [19:34] in juju 1.16 the bootstrap command didnt block but in 1.17 bootstrap runs synchronously and we are seeing it block for 10m [19:35] b/c of the way are scripts work during the cloud installation [19:35] should this be considered a bug? [19:35] our* [19:41] stokachu: most people consider it a feature [19:41] wrtp: hah [19:43] wrtp: did that behavior change between those versions? [19:59] stokachu: yes, behavior changed recently. I believe it was between those two releases that it went from async to sync. It's not a bug, it's intended, because otherwise it's hard to know when bootstrap succeeds, without spamming juju status. [20:00] stokachu: you can get previous behavior by simply running bootstrap asynchronously yourself [20:00] just push to the bg? [20:01] i thought there were talks on a switch [20:01] even though its intended is it not a bug since that is a breaking change from 1.16 to 1.17 [20:02] stokachu: it really shouldn't break anything unless you were counting on being able to get stuff done before the bootstrap node comes up, which is essentially purposely creating a race condition [20:03] stokachu: at worst it should make your script take longer, but it shouldn't *fail* [20:04] stokachu: there's a bootstrap-timeout value you can set in your provider to customize how long it'll wait for bootstrap to finish. It defaults to 10 minutes, which sounds like is not long enough for you. [20:05] stokachu: there's no switch because you can just do juju bootstrap& ... so no real need for a switch [20:05] ok [20:05] bbcmicrocomputer: ^ [20:06] stokachu: juju help bootstrap gives more details about customizing the timeout etc [20:07] natefinch: yea we'll probably incrase the timeout and background it [20:07] i think that'll work, thanks [20:10] stokachu: welcome [20:15] fwereade: ping [20:15] thumper, pong, I'm *finally* looking properly at that doc [20:15] fwereade: ok, could talk through a few ideas, may be helpful [20:16] thumper, sure, give me 5 mins to grab a drink [20:16] kk [22:58] thumper: do you have time for a hangout? [23:23] sinzui: hi, you still around? [23:23] I am [23:24] i found a problem with the metadata on https://juju-dist.s3.amazonaws.com/testing/tools/ [23:24] really! [23:24] well I shouldn [23:24] can you pull up https://juju-dist.s3.amazonaws.com/testing/tools/streams/v1/com.ubuntu.juju:released:tools.json [23:24] t question you. [23:24] see line 4 [23:24] "version": "1.17.2 [23:25] the version attr at that top level overrides the version at the item level [23:25] so it masks the various versions [23:25] waigani, so why did juju metadata do that? [23:25] and the 1.17.4 tools metadata records are hidden [23:25] wallyworld, , so why did juju metadata do that? [23:26] that i don't know - so you get juju metadata generate-tools ? [23:26] used [23:26] wallyworld, this looks the same, but it works. https://juju-ci.s3.amazonaws.com/tools/streams/v1/com.ubuntu.juju:released:tools.json [23:26] wallyworld, remember the logs show that the tools url was not used! [23:27] wallyworld, while we entered /testing/tools, juju used /tools [23:27] sinzui: what i did just now - i hacked juju so that it only uses tools-url, and then i did a juju metadata validate-tools [23:27] the debug shows tools-url is used [23:27] and shows that only 1.17.2 tools can be found [23:27] since that's the version at that top level [23:28] ah [23:28] 2014-02-25 23:21:03 DEBUG juju.environs.simplestreams simplestreams.go:535 using mirrored products path: https:/juju-dist.s3.amazonaws.com/tools/streams/v1/com.ubuntu.juju:released:tools.json [23:29] seems like it is getting the /tools from the mirrors file [23:29] let me check [23:29] wallyworld, slow down you are trying to solve a hack, not the actual problem [23:30] wallyworld, I am about to update juju-ci to use the proper url, you can watch the out and see that the tool-url is wrong, it is not what we entered [23:30] ok, but my debug shows tools-url is being used [23:31] and that it seems like mirrors processing then causes /tools to be used [23:31] There are no mirror files on aws [23:31] I set this tools-url: http://juju-dist.s3.amazonaws.com/testing/tools [23:31] wallyworld, the log has started http://162.213.35.54:8080/job/aws-deploy/860/console [23:32] and I see this [23:32] tools-metadata-url: http://juju-dist.s3.amazonaws.com/testing/tools. [23:32] and maybe to your point, the wrong juju was found [23:32] sinzui: while we wait, the cpc-mirros.json file on testing/tools has this [23:32] "mirror": "https://juju-dist.s3.amazonaws.com/tools", [23:32] "path": "streams/v1/com.ubuntu.juju:released:tools.json", [23:33] so my debug shows testing/tools is being used [23:33] well not you your point, to my point, the wrong url was used, so it looked at what I released last week and used it [23:33] but that then the mirrors file causes it to redirect to /tools [23:33] oh! [23:34] we don't permit mirrors files on the CPCs [23:34] huh? [23:34] only streams gets the file [23:34] i thought we did, so that the CPCs loaded tools locally [23:34] streams.canonical.com get it, and any site I choose to use as a proxy [23:35] so you saying that testing/tools should not have a mirror file? [23:35] waigani, but you are correct, that file got put there. [23:35] wallyworld: ^ [23:35] wallyworld, I am say that, nor should any CPC. why put a mirror file to the site you are on [23:36] sorry waigani [23:36] sinzui: no problem ;) [23:36] * sinzui starts purging [23:37] sinzui: if that console output had --debug that would show more info to help diagnose the issue and the search path used by simplestreams [23:39] wallyworld, I know, abentley doesn't care for that level of detail in the log [23:39] sure, normally i would agree. but it would have helped here :-) [23:39] wallyworld, new run http://162.213.35.54:8080/job/aws-deploy/861/console [23:39] maybe we can turn it on when there's an issue [23:39] the version is correct [23:40] sinzui: my validate-tools now passes [23:40] now that the mirros file is removed [23:41] $ juju metadata validate-tools [23:41] matching tools versions: [23:41] 1.17.4-precise-amd64 [23:41] it failed just before but works now [23:41] sinzui: It's not the level of detail that's the problem, it's the fact that it contain credentials. [23:41] wallyworld, in testing_to_aws in http://bazaar.launchpad.net/~juju-qa/juju-core/ci-cd-scripts2/view/head:/publish-public-tools.bash we do filter *mirror*. it has always been that way, but If someone put one there, it will not be removed by the sync op [23:42] does --debug contain credentials? Oh is the config output? [23:43] i would hope --debug doesn't contain credentials but if it does that sucks and should be fixed [23:44] sinzui: i've been thinking for a while i should add extra output to validate-tools to not only print the tools found but also the path from which they were got incl whether from tools-url vs cloud storage etc and whether a mirror was used [23:44] wallyworld: That's what I remember. [23:45] abentley: it may have been that way previously. i seem to have a vague, perhaps incorrect, recollection "someone" fixed it [23:45] i can verify that [23:45] s/can/will [23:45] wallyworld, that would be a lovely diagnostic. When I report bugs like this, I do test manually with --debug, I saw the urls switch, but did not notice the mirror use [23:45] wallyworld: I believe it was printing out the config, as sinzui suggested. [23:46] abentley: i think config is now sanitised to exclude credentials, but am not 100% [23:46] sinzui: if i add the extra output, the ci scripts could do a validate-tools at the state and check the output is as expected before bootstrapping and failing [23:46] s/state/start [23:46] wallyworld, they certainly can [23:47] same for image metadata [23:47] success [23:47] \o/ [23:47] * sinzui starts the upgrade job [23:47] * wallyworld crosses fingers [23:49] Finland has police raindeer. I bet the have fairy lights and bells instead of sirens [23:49] lol [23:51] * sinzui restores the url for the trusty tests [23:53] I am the likely person who put the mirror file there. I can't think how, but I will take the blame [23:54] sinzui: i do also want to get to the bottom of how we got those top level version attrs in the json. i'll check the ci scripts and metadata generation cmd in juju to see what might be going on [23:54] i'm just glad we found what was happening [23:54] and it gives me an excuse to spend the time to do better diagnostics [23:59] fab, all works, now that all the mirror files are deleted. Thank you very much wallyworld [23:59] no problem. pleased to help. i'm so grateful for the CI stuff you guys have done