[08:54] <jtv> roaksoax: I've got a branch going in soon that assumes that both the power-action templates directory and the pxe templates directory live in the same respective directories as the modules that make use of them.  So if you can install src/provisioningserver/pxe/templates in the same directory as src/provisioningserver/pxe/pxeconfig.py, and src/provisioningserver/power/templates in the same directory as src/provisioningserver/power/poweraction.py, that'll so
[09:34] <jtv> roaksoax: Hi.  I just landed a branch that should fix the problems you ran into yesterday with the pxe/power template directories, provided that the installed package install each of those two template directories in the same location as the respective module that makes use of it.
[09:34] <jtv> I'm stepping out now, back later!
[13:10] <jtv> rvba: reviewed your branch.  Thanks for writing it.
[13:58] <rvba> roaksoax: I've fixed most of the incompatibility issues I've seen yesterday (the only one remaining is about the API doc generation so it's not critical).  If you create a new package with the current trunk we will be able to investigate the wsgi issue.
[14:00] <roaksoax> rvba ok cool
[14:00] <roaksoax> leave me a few
[14:21] <jcharette> morning, i'd like some help with maas and juju
[14:33] <roaksoax> hi jcharette , ask your question and if someone is able to help you, he/she will
[14:34] <allenap> matsubara: \o/ re. Jenkins
[14:36] <matsubara> allenap, I'm pleased that you liked that your Highness. :-)
[14:36] <allenap> Haha :)
[14:39] <roaksoax> rvba: btw.. did you see the new yui3 package i uploaded to testing PPA?
[14:40] <rvba> roaksoax: ah, no I didn't.  I'll check it out.
[14:43] <jcharette> i'm trying to get juju and maas talking
[14:44] <jcharette> i've configured my juju environment to load the precise series
[14:44] <jcharette> juju seems to try to talk to maas
[14:44] <jcharette> but maas reports back that no matching node is available
[14:45] <jcharette> not really sure what that means, the maas console shows 6 nodes
[14:46] <roaksoax> jcharette: have the nodes been "Accepted & Commissioned"?
[14:46] <jcharette> hrm, they are stuck on 'commissioning'
[14:46] <jcharette> perhaps something is up with dhcp
[14:46] <jcharette> i'll investigate
[14:47] <jtv> hi there roaksoax — got my messages earlier?  About the failure with the templates directory that you hit the other day?
[14:48] <jcharette> is it possible to have a maas server dual homed
[14:48] <roaksoax> jtv: howdy! Yes I did, I'm building a new package to test
[14:48] <roaksoax> jcharette: you have to commission the nodes
[14:48] <roaksoax> jcharette: this means that for some reason WoL didn't work and didn't turn on the servers for them to commission
[14:49] <jcharette> i think its because i'm trying to dual home the maas server and have it handle dhcp for a private network of nodes
[14:49] <jcharette> hence WoL isn't kicking the boxes for provisioning
[14:51] <jcharette> is there a way to tell a node to stop trying to commission the box
[14:51] <jcharette> sorry, tell MAAS to stop trying
[14:51] <jcharette> (reading console and typing is a bad idea without coffee)
[14:52] <roaksoax> jcharette: maas is not trying to commission the node, maas is waiting for it to commission
[14:52] <jcharette> yeah, i want to remove the node and try an alternate approach
[14:53] <roaksoax> rvba: ^^
[14:54] <rvba> jcharette: hi, please have a look at this faq entry: http://askubuntu.com/questions/141106/how-do-i-delete-a-node-from-maas-after-removing-it-from-cobbler
[14:54] <jcharette> rvba: thanks
[14:58] <roaksoax> rvba: ok just uploaded a new version for you to play with. should build and publish soon
[14:58] <rvba> roaksoax: great
[15:00] <roaksoax> jtv: it seems to be working now: http://pastebin.ubuntu.com/1064431/
[15:01] <roaksoax> jtv: so does this mean maas-import-isos will eventually be ditched?
[15:15] <jcharette> roaksoax: looks like the problem i'm having is that VirtualBox doesn't support WoL
[15:23] <roaksoax> jcharette: plop, that's the nissue then
[15:23] <roaksoax> i thought you were using a real network
[15:23] <roaksoax> :)
[15:47] <roaksoax> rvba: any luck?
[15:48] <rvba> roaksoax: I was working on something else, I'm just getting started with the package now.
[15:48] <roaksoax> rvba: oh ok :)
[15:53] <rvba> roaksoax: Just installed the package.  There is an issue with the JS libs but the homepage loads ok (no wsgi error).
[15:53] <rvba> I'll investigate the JS libs issue.
[15:53] <roaksoax> rvba: uhmmmm now yui is installing in /usr/share/javascript/yui3
[15:53] <roaksoax> rvba: but I patched the settings
[15:53] <roaksoax> rvba: now, I wonder why this is not working in precise!
[15:54] <rvba> (I'm testing on Quantal)
[15:54] <roaksoax> rvba: right, but we are gonna be backporting this, so it *has* to work on precise
[15:55] <rvba> roaksoax: I know but I'm got only two hands and one brain so I'm taking this one step at a time :)
[15:55] <roaksoax> lol
[15:57] <roaksoax> rvba: btw.. can you quickly review https://code.launchpad.net/~andreserl/maas/pxe_power_template_install/+merge/112593 ?
[15:57] <roaksoax> when you have the chance
[15:57] <rvba> I'll get to it, just one sec.
[15:57] <roaksoax> rvba: no worries, take your time
[15:57] <roaksoax> thanks tyhough
[16:00] <rvba> roaksoax: libjs-raphael has not been installed when installing maas.  I suspect it's simply missing from the dependencies.
[16:01] <roaksoax> rvba: that's weird, I haven't removed it
[16:01] <roaksoax> rvba: did you make any change to source from the actual package instead?
[16:02] <rvba> roaksoax: I simply installed the package from the PPA on a brand new quantal install.
[16:03] <roaksoax> rvba: right, but I mean, in the maas source, did you do any change on how raphael is being sourced (i.e from /usr/share/javascript/raphael
[16:03] <rvba> roaksoax: no.  I installed the package manually and now it's picked up correctly.
[16:04] <rvba> roaksoax: so it's only a matter of adding it as a required dependency.  I /think/.
[16:04] <roaksoax> rvba: ok good
[16:04] <rvba> roaksoax:
[16:04] <rvba> arg
[16:05] <rvba> roaksoax: I found the issue:  there is a problem with the package.  Some files are missing.
[16:05] <rvba> roaksoax: all the files "*-min.js" it seems.
[16:06] <rvba> (that's in the copy of YUI in the tree): ls yui-base: yui-base-debug.js  yui-base.js  yui-base-min.js
[16:06] <roaksoax> rvba: so you use both? yui full's and mins's?
[16:06] <roaksoax> rvba: then install libjs-yui-min
[16:06] <rvba> That's in the package: ls yui-base: yui-base.js
[16:06] <roaksoax> rvba: I'll also depend on libjs-yui-min then
[16:07] <rvba> MAAS uses "-min" or the normal files depending on a debug setting.  But the default is to use "-min".
[16:08]  * rvba installs libjs-yui3-min.
[16:08] <roaksoax> rvba: i'll just depend on both
[16:09] <rvba> Sounds sensible.
[16:10] <roaksoax> rvba: btw.. I just realized we can't really ditch yui from trunk
[16:10] <roaksoax> nor raphael
[16:11] <rvba> roaksoax: why is that?
[16:11] <rvba> Precise compatibility I guess…
[16:11] <roaksoax> rvba: exactly
[16:12] <roaksoax> rvba: unless we also SRU raphael/yui, which we would be better off by not doing so
[16:12] <roaksoax> Daviey: I think we'd need to know the exact info as the packaging will differ at some point.
[16:13] <roaksoax> Daviey: at the moement, we were looking on ditching YUI/raphael from trunk but we can't since we are going to be backporting
[16:14] <roaksoax> rvba: ok so we need to make sure we don't introduce changes in wsgi that will make it not work in precise
[16:14] <rvba> roaksoax: sure.
[16:15] <rvba> roaksoax: I found one problem: we now have a new step to generate one js file.  When running "make enums", it will produce src/maasserver/static/js/enums.js.
[16:16] <roaksoax> rvba: got it.
[16:17] <roaksoax> rvba: is python-celery precise's version supported for MAAS? or we need quantal one?
[16:17] <rvba> roaksoax: we've been experimenting with precise so far.
[16:19] <roaksoax> rvba: ok so I'll get a maas version uploaded for precise that continues to ship yui from trunk
[16:19] <rvba> roaksoax: precise is still the main target platform for us.  I'm the only one helping you with quantal right now.
[16:20] <rvba> roaksoax: we'd like to get rid of the copy in our tree if that's possible of course.  But whether or not it's feasible to have the JS package in precise is up to you guys.
[16:21] <rvba> roaksoax: you're MP has been approved by Gavin "The Hawk" allenap. :)
[16:21] <roaksoax> rvba: right, IMHO, while we can backport raphael easily, I don't know about yui3 since it is cimpletely a new source package
[16:22] <roaksoax> rvba: lol, "The Hak"
[16:22] <roaksoax> rvba: lol, "The Hawk"
[16:22] <roaksoax> lol
[16:22] <roaksoax> allenap: \o/, Hawk!!
[16:22] <rvba> Always on the look-out for a MP to review :).
[16:23] <roaksoax> haha
[16:25] <rvba> If I copy manually enums.js, the JS loads up correctly.  I spotted another tiny problem but it has nothing to do with packaging so I'll spare you the description.
[16:26] <roaksoax> rvba: hehe ok
[16:30] <roaksoax> rvba: who handles the installer stuff?
[16:30] <roaksoax> rvba: makefiles/setup.py
[16:32] <rvba> roaksoax: you mean who in our team is the most familiar with the top-level file setup.py?
[16:32] <roaksoax> rvba: yeah... cause I think it would be better to have the enums.js file generation on the setup.py rather than in a makefile
[16:32] <rvba> allenap will know. :)
[16:32] <roaksoax> allenap: ^^
[16:36] <allenap> roaksoax: I have to go in -5 minutes, but I've been looking at that stuff recently. I was considering using Paver to streamline the process.
[16:37] <roaksoax> allenap: not in precise though :(
[16:41] <allenap> roaksoax: We can borrow Paver's ideas though.
[16:41] <allenap> Anyway, got to go! roaksoax, shall we talk about this tomorrow?
[16:42] <roaksoax> allenap: sure thing
[16:42] <roaksoax> thanks
[16:45] <rvba> roaksoax: I need to go too… I'll test the package on precise tomorrow morning and let you know how it works.
[16:45] <roaksoax> rvba: cool, thanks! Have a good one man
[16:45] <rvba> You too.
[20:14] <roaksoax> Daviey: ok I have a working MAAS package for quantal and precise. Will upload yui3 on friday though, and then maas
[20:14] <roaksoax> smoser: ^^
[20:15] <Daviey> roaksoax: awesome!
[20:16] <Daviey> roaksoax: gah, dammit.. I was going to give you a squashfs
[20:17] <roaksoax> Daviey: hehe ok :)
[20:18] <smoser> wow, roaksoax ! nice work.
[20:18] <roaksoax> smoser: heh, it wasn't that bad as last cycle :)
[20:18] <smoser> i was hopign to get a response on my suggestion for oauth fix from bigjools
[20:18] <smoser> oauth timestamp fix
[20:18] <Daviey> smoser: bigjools won't be around much the next couple of weeks.
[20:18] <roaksoax> smoser: good thing is that we are still before FFe so we can upload to quantal as many times as we can
[20:19] <roaksoax> smoser: we can get things tested in quantal, and once ready we can just take care of precise
[20:20] <smoser> Daviey, roaksoax did you read my mail?
[20:20] <smoser> what did you think of that solution.
[20:20] <smoser> moderately hacky, requires a "web time service"
[20:20] <roaksoax> smoser: reading at it now
[20:22] <roaksoax> smoser: sounds good to me, simple enough and very SRU'able
[20:44] <roaksoax> smoser: free? would you care to review https://code.launchpad.net/~andreserl/maas/quantal_packaging_changes_bzr697/+merge/112649 ?
[20:44] <smoser> i'll take a quick look
[20:47] <roaksoax> smoser: thanks
[20:51] <smoser> roaksoax, is your start on right?
[20:52] <smoser> it doesn't seem right to me
[20:52] <roaksoax> smoser: it is not a final revision to be released
[20:52] <smoser> you can start without all network devices up, but need *some* device up?
[20:52] <smoser> (well, you asked for review!)
[20:53] <smoser> what does celeryd do?
[20:53] <smoser> and shouldn't you be telling it to use celeryconfig.py ? somewhere?
[20:55] <roaksoax> smoser: celeryd is basically the cobbler replacement
[20:55] <smoser> ok.
[20:55] <smoser> i just dont see how you are giving it any configuration
[20:55] <smoser> or how it would know about maas in any way
[20:56] <roaksoax> smoser: the configuration lies in it being in the pythonpath
[20:56] <roaksoax> smoser: same way as it is being done with maas_local_settings.py
[20:56] <smoser> what pythonpath?
[20:56] <roaksoax> it is installed in /etc/maas/ and symlinked into /usr/share/maas/
[20:56] <smoser> how are you telling pythopath to celeryd?
[20:56] <smoser> i'm confused.
[20:56] <smoser> oh... the maas user maybe?
[20:57] <roaksoax> smoser: celeryd by default sources those paths
[20:57] <roaksoax> so if the config is available to it, then it is used
[20:57] <roaksoax> smoser: I don't know the design principles of it, but that's how it works
[20:57] <roaksoax> smoser: similar way to how twistd does it
[21:00] <smoser> "by default sources those paths"
[21:00] <smoser> what paths?
[21:00] <roaksoax> smoser: PYTHONPATH
[21:01] <smoser> well, that does make senes. so the maas user has PYTHONPATH set to /etc/maas ?
[21:01] <roaksoax> smoser: nop
[21:01] <roaksoax> smoser: maas is installed in /usr/share/maas
[21:02] <smoser> right.
[21:02] <smoser> i see that.
[21:02] <roaksoax> smoser: the configs are installed in /etc/maas/maas_local_settings.py and /etc/maas/celeryconfig.py
[21:02] <smoser> is thre a reason you link it into /etc/maas ?
[21:02] <roaksoax> smoser: then they are symlinked into /usr/share/maas, where they are sourced from
[21:03] <smoser> o.
[21:03] <smoser> tha tmakes rasonable sense.
[21:03] <smoser> you refreshed: debian/patches/01-fix-database-settings.patch
[21:03] <roaksoax> smoser: yep
[21:03] <smoser> just because. i guess thats fine.
[21:04] <roaksoax> smoser: heh, not just because but there were offsets that I thought would be best not to have
[21:06] <smoser> ok. so i have to run
[21:07] <smoser> my only request then is that you comment in /etc/init/maas-celery.conf that the config is picked up out of /etc/maas/
[21:07] <smoser> and maybe say how
[21:07] <smoser> for dummies like me
[21:07] <smoser> to whom that is not obvious
[21:10] <roaksoax> smoser: done, if you feel ok to approve it would be great