[00:04] <roaksoax> bigjools:  ti is a recommends of python-bson
[00:04] <roaksoax> which would get installed as part of bson's installation i think
[00:06] <bigjools> ok
[01:55] <jpds> smoser: Do you know why cloud-tools wants to remove ubuntu-minimal? https://pastebin.canonical.com/98848/
[02:00] <smoser> jpds, don't know. but i'd like to knwo. same with dhcp-client doesn't make any senes.
[02:00] <smoser> will investigate manana if you dont want to now
[02:01] <jpds> I can now.
[02:01] <jpds> If you want some apt-cache outputs ror something.
[02:22] <danwest> smoser: current fpi image is 12.04.1, not 12.04.3?
[02:27] <smoser> danwest, we can/should update that.
[02:27] <smoser> we really need to get that on a 3 week like cadence.
[02:28] <danwest> smoser: k, just noticed it
[02:28] <smoser> .X is really garbage
[02:28] <smoser> it does show its old
[02:28] <smoser> but .X versus .Y doesn't mean anything.
[02:35] <smoser> jpds, http://paste.ubuntu.com/6216432/
[02:35] <smoser> thats the reason
[02:35] <jpds> smoser: Nice.
[02:39] <smoser> jtv, or bigjools, would you please take a cursory look at http://paste.ubuntu.com/6216361/
[02:39] <jtv> Looking...
[02:39] <smoser> it still has printfs in it. but some of tha tis important
[02:39] <smoser> i think right now when we ryn 'sync' it will end up re-extrracting the tarball pointlessly
[02:39] <smoser> and has no status on download at all.
[02:39] <jtv> What am I looking at?
[02:40] <smoser> patch to mass-import-ephemerals that adds
[02:40] <smoser>  * some bad status on stderr
[02:40] <smoser>  * not needlessly extracting a 250M tarball multiple times
[02:40] <smoser>  * basically says "if stuff is in place, its good"
[02:40] <smoser> and dont put files in place until they're good.
[02:41] <jtv> Great.
[02:42] <jtv> I think there's still some debug output in there...
[02:42] <jtv> Of course tests will need updating.
[02:42] <smoser> yeah i said that :)
[02:42] <smoser> printf debugging still there
[02:43] <jtv> Not what you said.
[02:43] <jtv> But it falls into place when you word it that way.
[02:43] <smoser> yeah.
[02:44] <smoser> jpds, would you mind opening a bug ?
[02:44] <smoser> with our discussion above ?
[02:44] <smoser> i'll now upload iproute2 to staging
[02:44] <smoser> or... to -next
[02:44] <smoser> and i think that will actually solve our problem
[02:44] <jpds> smoser: In a sec, doing a live MAAS demo.
[02:45] <jtv> It's a lot of changes for one branch.  If feasible, I'd advise breaking it down into smaller branches.
[02:45] <smoser> jtv, yeah.
[02:45] <jpds> smoser: Bug where?
[02:45] <smoser> you can open against cloud-archive project
[02:45] <jpds> Will do.
[02:48] <smoser> jtv, the other hting that we're doing now that we really dont need to do is actually caching the .tar.gz files that are downloaded.
[02:48] <smoser> that increases the size requirements for /var/lib/maas
[02:48] <smoser> we dont need them really. its a side affect of using the mirror that we're using.
[02:51] <jtv> I was wondering about that.  Those files are huge.
[02:51] <jtv> It's been complicating testing, even.
[02:52] <jtv> Will the mirror writer still function well when we delete those files?
[02:52] <jtv> I mean, it won't re-download images we already have, that sort of thing?
[02:55] <jtv> The docstring for extract_image_tarball needs updating.  It's hard to figure out these changes from code without any explanation, but it's especially hard for the next person maintaining the code because they'll get documentation that is basically a lie!
[02:58] <jpds> smoser: https://bugs.launchpad.net/cloud-archive/+bug/1237751
[03:03] <roaksoax> smoser: are your fixes for import-ephemerals hitting trunk?
[03:15] <jtv> smoser: another note about the diff, besides "document!": we normally require boolean tests to be explicit about what they test, e.g. "if name is not None:" or "if len(items) == 0:" instead of just "if name" or "if not items" respectively.
[03:20] <roaksoax> jtv: is anything else landing nowish?
[03:31] <jtv> roaksoax: not that I know.
[03:31] <roaksoax> jtv: ok, just uploaded maas anyway
[03:32] <jtv> There are two approved branches, from Gavin & Raphaël respectively.  I could see if they need immediate landing.
[03:34] <jtv> Gavin's is irrelevant for production, and Raphaël may still want to consider options for his branch.
[03:36] <jtv> smoser: don't forget to document dlstatus()... it also needs a clearer name, preferably a verby one!
[03:41] <jtv> smoser: By the way, can you explain what "flat" is, in insert_item?  It gets returned from from util.products_exdata.
[03:42] <jtv> Oh, and don't forget to run "make lint" — it catches some of the most obvious violations of coding standards.
[04:19] <bigjools> jtv: any outstandng problems that you know of?
[04:22] <jtv> bigjools: no, I was waiting to ask you the same thing.  Scott has a patch he's working on.
[04:22] <bigjools> there's allenap's bson problem
[04:22] <bigjools> that's all I know
[04:27] <bigjools> jtv: if you're up for a technical challenge, see bug 1237615
[04:32] <jtv> Slightly under the weather, probably post-deadline letdown, but I'll give it a look.
[04:47] <bigjools> jtv: it's possible the garage maas is buggered - first st
[04:47] <bigjools> jtv: it's possible the garage maas is buggered - first step is to recreate
[05:45] <jtv> bigjools: afaict we're not actually implementing the workaround from that blog article — we have WSGIApplicationGroup %{GLOBAL} but not WSGIProcessGroup %{GLOBAL}.
[05:46] <jtv> I still feel I'm missing something though...  If we're running only one application, what other interpreter in the same process is using the bson extension?
[06:29] <bigjools> jtv: threads
[06:29] <bigjools> it broke in other ways without the WSGIApplicationGroup too
[07:20] <jtv> bigjools: it says threads=1, so that's part of the picture I'm missing.  But I'm not saying WSGIApplicationGroup %{GLOBAL} looks wrong, just that we don't have the workaround the blog article suggested.
[07:56] <bigjools> jtv: hmmm
[07:56] <bigjools> it also says processes=2
[08:00] <bigjools> roaksoax: so is the bson issue resolved?
[08:00] <bigjools> and rvba ^ ?
[08:00] <lifeless> is bson biting?
[08:01] <lifeless> is it from oops, or something else that you're using bson for? </idlecuriosity>
[08:01] <bigjools> lifeless: python-bson and wsgi don't get along
[08:01] <bigjools> https://launchpad.net/bugs/1237615
[08:01] <lifeless> bigjools: wsgi in general, or mod_wsgi.. ah
[08:02] <rvba> bigjools: I don't know, allenap was looking into it… Gavin ^?
[08:03] <bigjools> rvba: the reason I ask is because of the last comment you made on the email thread
[08:03] <bigjools> "Andres figured it out… I tested his fix in the lab and it worked! "
[08:05] <rvba> bigjools: right, but the title of the email says "Commissioning with a Saucy image sets node status to "Failed tests"" and the bug referenced in there is bug 1237364 .
[08:06] <bigjools> rvba: urgh right
[08:23] <bigjools> see this? https://bugs.launchpad.net/bugs/1237615
[08:23] <bigjools> argh
[08:23] <bigjools> https://bugs.launchpad.net/bugs/1237615
[08:23] <bigjools> no
[08:23] <bigjools> paste fail
[08:24] <bigjools> https://bugs.launchpad.net/bugs/1237159
[08:24] <bigjools> that
[08:24] <bigjools> rvba: ^ ?
[08:25] <rvba> Looking…
[08:26] <bigjools> looks like the "ownership" bug combined with the "cruft left in the filestore" bug
[08:27] <rvba> "cruft left in the filestore"?
[08:28] <rvba> I just think juju is trying to release all the nodes it can see (the juju-core bug) and some of the nodes' status don't allow that transition.
[08:28] <bigjools> yeah
[08:45] <jpds> bigjools: Are you stlil around?
[08:47] <jpds> MAAS is doing something quite special.
[08:50] <jpds> Actually, no, that's just very confusing.
[12:19] <smoser> jpds, did you open me a bug ?
[12:24] <jpds> smoser: Yes.
[12:24] <smoser> oh?
[12:24] <smoser> i didn't see it. and just opened one myself.
[12:24] <jpds> smoser: https://bugs.launchpad.net/cloud-archive/+bug/1237751
[12:31] <smoser> jpds, just copied iproute2 from -staging to -proposed.
[12:31] <smoser> it has to re-build there, but then wlil land.
[12:32] <jpds> smoser: Cool.
[13:26] <roaksoax> allenap: howdy
[13:26] <roaksoax> allenap: did you test the wsgi issue in a clean environment ?
[13:27] <roaksoax> allenap: and unfortunately we cant do anything about pyhon-bson-ext being installed
[13:27] <roaksoax> it will be
[13:29] <allenap> roaksoax: I tried it in the garage maas. Moving _cbson.so out of the way (and restarting apache) fixed it. fixed it
[13:30] <roaksoax> allenap: but what was the issue in the first placr.. the bug doesnt really say
[13:31] <roaksoax> allenap: i would tests in a clean environment
[13:31] <mgz> roaksoax: mod_wsgi uses a simplified threading model that not all python c extentions are compatible with
[13:31] <mgz> symptom is generally segfaults
[13:31] <roaksoax> mgz: right
[13:32] <roaksoax> but my question is... do maas webui dies? does celery die?
[13:34] <allenap> roaksoax: Nothing so obvious. It encodes binary data as UTF-8 strings, which causes an exception in the celery worker on the cluster, thus preventing tag expressions from being recalculated en masse.
[13:35] <roaksoax> allenap: can you provide an exact way to reproduce and see how it fails to donso(we will need it eventuslly fornsru if we find a solution) but would like to test in a clean environment
[13:36] <roaksoax> it would not be the first time i see issues doe tue a broken environment
[13:36] <roaksoax> issues due to*
[13:39] <roaksoax> thanks ;)
[13:49] <allenap> roaksoax: I'll try to reproduce in a dev environment.
[14:27] <roaksoax> allenap: thank you!
[14:33] <stokachu> re: bug https://bugs.launchpad.net/maas/+bug/1237723, going to start work on this today, would like some feedback on comment #3
[15:33] <stokachu> so should the maas api be exposing things like network information (vlans) ?
[15:34] <stokachu> i would think we'd need some sort of agent on the machines to respond to those types of requests
[15:35] <stokachu> i did something like this before using qpid
[15:35] <stokachu> amqp
[15:36] <allenap> stokachu: Currently it exposes the routers to which a machine is connected, as discovered by LLDP. It also records the LLDP XML as produced from lldpctl in the lldpd package which can be used for tag expressions.
[15:36] <stokachu> allenap: ok im not entirely familiar with lldp so ill need to research that
[15:37] <allenap> stokachu: When I say "currently", I mean as of this week :)
[15:37] <stokachu> ahh
[15:38] <stokachu> allenap: im going to go digging into the code today to make sense of it
[15:41] <allenap> stokachu: We are behind with documenting it, so please ask if you have questions. To the maas-devel mailing list is probably best, so that we have a record and others see it.
[15:46] <stokachu> allenap: ok will do thanks!
[16:11] <stokachu> allenap: awesome lldp gathers the vlan name
[16:11] <stokachu> so i can work to expose that information b/c so far i think maas only exposes the mac address
[16:25] <roaksoax> allenap: so have you guys tested DHCP with portfast + LLDP?
[16:26] <roaksoax> allenap: in real world escenarios we've seen that that portfast prevents nodes from obtaining DHCP
[16:27] <allenap> roaksoax: I haven't, and I don't think rvba or anyone else has.
[16:28] <roaksoax> that's probably gonna conflict wouldn't it? since I read somewhere that the lldp needs portfast enabled
[16:47] <stokachu> do you guys have switches to test against
[16:47] <stokachu> i dont have any of that hardware and im not sure if openvswitch would emulate vlans in the same manner as cisco
[16:59]  * roaksoax bbl
[17:12] <smoser> matsubara,
[17:12] <smoser> when the QA lab tests, does it test with released images or dailies ?
[17:15] <matsubara> smoser, it uses the image from: CLOUDIMGURL=http://cloud-images.ubuntu.com/$RELEASE/$BUILDID as the testbed
[17:15] <smoser> matsubara, i'm sorry. i meant the ephemeral images.
[17:16] <smoser> maas.ubuntu.com/images
[17:22] <matsubara> smoser, hmm we have a local mirror of maas.ubuntu.com/images here: http://10.98.0.13/mirrors/maas-ephemeral/, then the tests configure /etc/maas/import_ephemerals to use that mirror. (See http://bazaar.launchpad.net/~maas-maintainers/maas/qa-lab-tests/view/head:/utils.py lines 70  to 92). The test used to set up STREAM=daily but that's been disabled a long time ago as you can see by the XXX there
[17:33] <smoser> matsubara, could i get a run done with daily ?
[17:34] <matsubara> smoser, sure. let me trigger that for you. give me a few
[17:34] <smoser> k. thanks.
[17:35] <smoser> roaksoax, how does maas-import-ephemerals get run ?
[17:35] <matsubara> smoser, with the saucy maas package, I assume?
[17:35] <smoser> matsubara, sure
[17:38] <roaksoax> maas-imoort-pxe-files runs it
[17:39] <roaksoax> smoser ^^
[17:40] <smoser> roaksoax, when does that get run
[17:40] <matsubara> smoser, Currently rvba left a job running (#90) but I queued a test run with the STREAM=daily enabled. It's going to be build #91 on jenkins: http://10.189.74.2:8080/job/saucy-adt-maas-manual/
[17:41] <matsubara> smoser, I'll keep an eye on it and let you know how it goes
[17:41] <smoser> matsubara, thanks.
[17:41] <matsubara> np
[17:43] <roaksoax> smoser: i font think we have a cronjob anymore
[17:44] <smoser> Hooray for us.
[18:27] <matsubara> smoser, the test run you asked is running: http://10.189.74.2:8080/job/saucy-adt-maas-manual/91/ARCH=amd64,label=lenovo-RD230-01/console, looks like the STREAM=daily didn't cause any problems and the tests are running the juju tests now. You can inspect the test instance running MAAS here: http://10.98.0.90/MAAS/nodes/
[18:29] <matsubara> I don't remember exactly the reason why STREAM=daily was commented out from import_ephemerals but I think there's a small window between when a release is made and the new devel images are avaialble in maas.ubuntu.com/images
[18:29] <matsubara> need to ask rvba about that as it was his XXX :-)
[18:32] <smoser> matsubara, there were bugs in the images.
[18:33] <smoser> mainly i think before https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1050487 was backported
[18:58] <matsubara> smoser, tests passed. should I MP the change to re-enable the STREAM=daily on import_ephemerals? I kicked off test runs for precise, quantal and raring too just to be sure.
[18:59] <smoser> matsubara, i think i'd prefer that, yeah.
[18:59] <smoser> it probably only acutally tests precise enlistment though, right?
[19:00] <matsubara> smoser, yes
[19:00] <smoser> ewll, for this purpose thats pretty good.
[19:01] <smoser> matsubara, would it be easy to tell it to use a different release ?
[19:01] <smoser> i dont recall how you tell it to use a different release for commissioning than precise
[19:04] <matsubara> smoser, we have a NODE_SERIES variable but that's used to tell juju which release to use for deployment. If the maas cli allows us to change the main maas setting for commissioning, then it should be easy to do.
[19:05] <smoser> roaksoax, do you know ?
[19:06] <matsubara> smoser, apparently it's possible, yes: http://maas.ubuntu.com/docs/configure.html#choosing-a-series-to-install
[19:06] <smoser> thats just the defaul treleease.
[19:06] <smoser> i dont know if it that is used for commissioning
[19:07] <smoser> hm..
[19:09] <smoser> matsubara, well, its             release=Config.objects.get_config('commissioning_distro_series'))
[19:19] <matsubara> well, looks like that's setable using the maas-cli: $ maas-cli maas maas get-config name="commissioning_distro_series"
[19:19] <matsubara> "precise"
[19:23] <smoser> nice.
[19:29] <matsubara> cool. I added a new COMMISSIONING_SERIES var to the test (Default to precise) which allows us to run the tests with MAAS commissioning with different releases. I'll MP and ask for a review from the maas guys
[19:33] <roaksoax> matsubara: commissioning has it owns drfault variable so does deployment
[19:33] <roaksoax> juju passes fhe release for deployment
[19:33] <smoser> yeah. we saw. and go tthat right.
[19:34] <roaksoax> if juju does pass it then it uses default or the one set
[19:34] <smoser> juju
[19:34] <roaksoax> thats why we need default-series in the environment for juju
[19:34] <smoser> there are other things than juju ;)
[19:34] <roaksoax> in environments.yaml
[19:34] <smoser> we were talking about commissioning though
[19:35] <smoser> which has nothing to do with juju
[19:35] <smoser> (i know, roaksoax, saying something has nothing to do with juju is shameful to you)
[19:35] <roaksoax> commissioning you only need to set the variable
[19:36] <roaksoax> smoser: haha it is not was just trying to give background info
[19:47] <allenap> roaksoax: I've got a simple fix for the bson bug.
[19:48] <allenap> roaksoax: I've confirmed it works on the Garage MAAS, and I have a reproducible example (see https://bugs.launchpad.net/ubuntu/+source/pymongo/+bug/1237615).
[19:48] <allenap> roaksoax: I'll put up a branch for review in a few seconds.
[19:50] <allenap> roaksoax: https://code.launchpad.net/~allenap/maas/fix-wsgi-application-group/+merge/190458
[19:51] <roaksoax> allenap: cool thanks
[20:06] <allenap> roaksoax: If you review it, I land it, can we rebuild and upload in time?
[20:07] <roaksoax> allenap: so what's the regression potential of doing this "application-group=%{GLOBAL}"
[20:07] <roaksoax> allenap: i mean, could that affect how other things such as logs? or anything else that requires everything under wsgi to run under the maas user/grpup
[20:08] <allenap> roaksoax: I honestly don't know. The change ensures that the wsgi.py script is imported in the first Python interpreter to be created instead of a later one. My guess is that this is what we wanted all along anyway.
[20:09] <allenap> roaksoax: Right now tag recalculation isn't working at all :-/
[20:12] <roaksoax> allenap: right, so we are between the sword and the wall...
[20:13] <allenap> roaksoax: Indeed!
[20:13] <roaksoax> allenap: let's get that tested in many ways possible and if there's no apparent issue, let's merge it
[20:13] <allenap> rvba: Are you able to help test a new package in the lab?
[20:14] <roaksoax> allenap: we will need to test both upgrades and fresh installs
[20:14] <allenap> roaksoax: I don't have the means to test those. matsubara, do you?
[20:15]  * matsubara reads backlog
[20:15] <matsubara> I can test on the qa lab
[20:15] <matsubara> would that help?
[20:17] <roaksoax> we need to check that everything starts, that all the logs are written
[20:17] <roaksoax> we need to make sure no errors are present in apache logs
[20:17] <roaksoax> nor maas logs
[20:17] <roaksoax> power commands
[20:17] <matsubara> allenap, roaksoax: what's the package that needs fresh install testing? And what upgrade path do you want me to test? raring to saucy and or precise to saucy (not even sure if that's possible)?
[20:17] <roaksoax> everything that involes wsgi
[20:17] <roaksoax> matsubara: saucy archives, to saucy fix
[20:19] <allenap> roaksoax: Can you +1 https://code.launchpad.net/~allenap/maas/fix-wsgi-application-group/+merge/190458 and I'll start the ball rolling.
[20:19] <matsubara> the lab is currently tied up running some tests for smoser, once that's done (should be done in a couple of hours) then I can do the testing
[20:19] <matsubara> which will give you guys time to land and get the recipe going to build a new package, right?
[20:25] <allenap> matsubara: Should be. Thanks Diogo, that's great.
[20:32] <allenap> matsubara, roaksoax: I've requested a built at https://code.launchpad.net/~julian-edwards/+recipe/maas-daily-saucy
[20:34] <matsubara> allenap, there's a message there saying it couldn't build because sp was superseded. is this related to build you requested?
[20:34] <allenap> matsubara: I think that's an old message.
[20:35] <matsubara> allenap, ok
[20:50] <allenap> roaksoax: That built fine, but https://code.launchpad.net/~maas-maintainers/+archive/dailybuilds says a newer version is in the distro. How can I fix this?
[21:07] <roaksoax> allenap: oh hold on
[21:09] <roaksoax> allenap: ok changes to packaging should land in a few minutes
[21:09] <roaksoax> allenap: https://code.launchpad.net/~andreserl/maas/packaging_bzr1693/+merge/190488
[21:11] <allenap> roaksoax: When they're in I'll kick off a new build.
[21:11] <roaksoax> allenap: merged, go for it
[21:11] <roaksoax> allenap: i need to leave now, will be back tonight. Just email me an update and I'll do my share of testing when I get back
[21:13] <allenap> roaksoax: That's brilliant. It's bedtime for me, so I'll speak to you tomorrow.
[21:14] <roaksoax> allenap: alright! thanks for thr hard work
[21:14] <allenap> roaksoax: You too :)
[21:15] <matsubara> allenap, could you cc me too? would be helpful to have some pointers on what I need to test for
[21:17] <matsubara> allenap, roaksoax: from the conversation above, I'm thinking of doing: start a new saucy testbed, install the saucy package from the archive, upgrade it to the PPA version and then check logs, web ui. Anything else I should check for?
[21:17] <allenap> matsubara: The thing that has to work is tag expression recalculation. When you define a new tag, or update and existing tag, containing an XPath expression, jobs get sent to the clusters asking them to do the work. The jobs on the clusters were crashing with ValueError (https://bugs.launchpad.net/maas/+bug/1237463).
[21:19] <matsubara> allenap, cool. thanks for the bug.
[21:19] <allenap> matsubara: What you need is a node that has completed commissioning (and so has lshw and/or lldp XML recorded against it) and then add a new tag with an expression (the expression "true()" - without quotes - is enough to test this).
[21:21] <matsubara> allenap, perfect. thank you
[21:36] <allenap> matsubara: 1.4+bzr1693+dfsg-0+1695+210~ppa0~ubuntu13.10.1 is now available in ppa:maas-maintainers/dailybuilds.
[21:37] <matsubara> allenap, the lab should be available soon and will get the testing started
[21:37] <allenap> matsubara: Tip top, thanks again. I'm going to get some sleep now. Cheerio until tomorrow.
[21:38] <matsubara> allenap, you're welcome. good night!
[22:43] <bigjools> morning
[23:34] <bigjools> roaksoax: why add power/moonshot.template which is an almost carbon copy of ipmi?
[23:35] <bigjools> it has an old bug in it (bug 1171418)
[23:37] <roaksoax> bigjools: ipmitool?
[23:37] <roaksoax> moonshot uses ipmitool
[23:38] <roaksoax> bigjools: besides we need a template named moonshot eithwrway
[23:38] <bigjools> really?
[23:38] <roaksoax> to use thst power method
[23:38] <roaksoax> yep really
[23:38] <bigjools> why not make it generic "ipmitool"
[23:38] <bigjools> either way, it has a bug
[23:39] <bigjools> and I am sure we can refactor it with ipmipower
[23:39]  * bigjools files bug
[23:39] <roaksoax> bigjools: it does not worl exactly as the one using ipmipower
[23:39] <bigjools> roaksoax: what are the main differences?
[23:39] <roaksoax> the behavior is different
[23:40] <roaksoax> bigjools: t
[23:40] <roaksoax> wwhat moonshot returns on ipmi commands
[23:40] <roaksoax> on ipmi power we use cycle
[23:40] <roaksoax> ipmitool doesnt
[23:41] <bigjools> :/
[23:42] <roaksoax> yeah it sucks
[23:42] <roaksoax> but btw when the power typenis set to "moonshot" the code looks for a template cslled moonshot.template
[23:43] <roaksoax> anyway im off
[23:44] <bigjools> roaksoax: ok fair enough... it's a shame.  Thanks for getting loads of stuff fixed, tremendous job!