[02:25] <rbasak> bigjools: thanks. I was going to fill out that bug - I just created it to track the work to start with.
[02:25] <bigjools> rbasak: :)
[02:25] <rbasak> bigjools: I've fixed the test issue with iscpy locally. Just sorting an upload out for that now.
[02:25] <bigjools> I had it on my list of things to do anyway, I didn;t know you were doing it
[02:25] <bigjools> oh!
[02:25] <bigjools> I was just doing *that* as well
[02:26] <rbasak> I had to patch a test - just sending that upstream now, then I'll upload
[02:26] <rbasak> roaksoax (via gaughen) asked me if I could take care of these two MIRs.
[02:27] <bigjools> rbasak: oh, tests all ran for me
[02:28] <rbasak> bigjools: yeah they run fine, but can't find their data if the working directory is the top level, which is the normal way for nosetests to run.
[02:29] <rbasak> bigjools: http://paste.ubuntu.com/7160450/ is what I did. Just used __file__ to make the test a bit more resilient finding its own data.
[02:29] <rbasak> Then nosetests runs fine.
[02:29] <bigjools> ok
[02:31] <bigjools> rbasak: looks almost exactly what I had done so far
[02:31] <bigjools> so I'll let you finish I guess :)
[02:32] <rbasak> bigjools: I'm just sending the patch upstream, then I'll upload. Sorry about duplicating work.
[02:32] <rbasak> I had assumed that roaksoax owned it and had handed it to me.
[02:32] <bigjools> rbasak: no worries, let's just blame roaksoax :)
[02:32] <rbasak> :)
[02:33] <jtv> Hi rbasak — what are you doing up at this hour?
[02:34] <rbasak> jtv: can't sleep. I have body clock issues :(
[02:34] <rbasak> I figured I'd work now and sleep later, rather than remaining sleep deprived today.
[02:38] <jtv> I find that unless I work until the point of collapse, I need a few hours to unwind after work.
[02:38] <jtv> Otherwise, no sleep again.
[02:45] <rbasak> I think I more or less understand my body clock and how to fix it. I have a really bright daylight lamp on a timer switch.
[02:45] <rbasak> Unfortunately life got in the way and my body clock gets disrupted very easily.
[02:46] <jtv> Same here, though I found ways of coping.  Probably not as bad as you.  Never got Redshift to work, but it sounded like a good idea.
[02:46] <rbasak> The lamp should fix it in a week or so though. Luckily it's only slightly annoying, especially with a job where I can mostly just get on with it without worrying about working hours.
[02:47] <rbasak> Meetings excepted, but I don't have so many so can usually manage to make those.
[02:47] <rbasak> (well, always, I think so far)
[02:47] <jtv> On the bright side, you get to talk to colleagues you wouldn't normally have much overlap with.  :)
[02:47] <rbasak> Indeed :)
[03:06] <rbasak> jamespage: we need to be subscribing ~ubuntu-server to MAAS MIRs, right If so, could you please subscribe us to iscpy and to python-seamicroclient?
[03:06] <rbasak> We have MIRs active on these now, and I've linked the MAAS blueprint to the bugs.
[03:06] <rbasak> roaksoax: ^^?
[03:07] <bigjools> rbasak: it must be 3am for you... wtf? :)
[03:07] <rbasak> bigjools: see backscroll :)
[03:08] <bigjools> rbasak: get a blood test for MTHFR mutation
[03:08] <bigjools> and then read this http://mthfr.net/mthfr-c677t-mutation-basic-protocol/2012/02/24/
[03:08] <rbasak> So python-seamicroclient appears to be running tests, but they are failing and the failing results are explicitly being ignroed with a ||true
[03:08] <bigjools> !!!
[03:09] <bigjools> kwality
[03:31] <bigjools> jtv: I am going to have lunch then I will review your branch
[03:33] <jtv> Thanks.
[03:36] <jtv> Sometimes I wonder what systems would look like if the world had an iron-clad engineering rule: you can't land code that grabs a persistent lock without a watchdog to protect against process death.
[03:37]  * jtv just rebooted a system to get rid of an apt lock.  Does it show?
[06:25] <jamespage> rbasak, ok
[07:34] <dimitern> hey maas guys, I'm wondering how can I install maas 1.5 from the package here https://launchpad.net/ubuntu/trusty/+source/maas/1.5+bzr1977-0ubuntu5
[07:35] <dimitern> I have a local install with maas (originally on precise using v1.2, but then upgraded to 1.4) with libvirt vm as cluster controller and 5 vm nodes, which is working well with juju
[07:36] <dimitern> so, can I install 1.5 on precise? i've added the cloud-tools pocket but can't see newer version than 1.4
[07:36] <dimitern> rvba, perhaps you can help? ^^
[07:37] <bigjools> dimitern: hi
[07:37] <rvba> AFAIK, 1.5 is not available on precise.  You need trusty.
[07:37] <rvba> dimitern: ^
[07:37] <bigjools> what he said :)
[07:37] <dimitern> bigjools, hey
[07:37] <bigjools> dimitern: you need trusty
[07:37] <dimitern> so I can try installing a new maas on trusty and I should get the latest
[07:38] <bigjools> not the very latest but it will have the latest VLAN code
[07:38] <dimitern> cheers bigjools and rvba
[07:38] <bigjools> dimitern: canonistack to the rescue!
[07:38] <dimitern> bigjools, why canonistack?
[07:39] <bigjools> dimitern: I'm sure you'll figure it out
[07:39] <dimitern> :) oh boy
[07:40] <dimitern> and this time i'm writing everything down each step of the way and will post a yet another "installing maas+juju" blog article :)
[08:19] <basicer> How would I go about changing how Curtin creates the filesystem ?
[08:33] <bigjools> basicer: you wait for smoser to come online and get him to help :)
[08:34] <jam> rvba: just checking if https://launchpad.net/~maas-maintainers/+archive/dailybuilds/+packages is appropriate if we want to set up our own MaaS to do testing against VLAN
[08:34] <jam> or if that is going to be *too* new and sometimes broken
[08:35] <jam> I guess I see this one, too: https://launchpad.net/~maas-maintainers/+archive/daily-qa-ok
[08:35] <rvba> jam: not sure the package in daily-qa-ok is recent enough.
[08:35] <bigjools> rbasak: it is
[08:35] <jam> rvba: 1.5+bzr1977+2115+246~ppa0~ubuntu14.04.1
[08:35] <bigjools> rvba:  it is
[08:35] <jam> says 2115 in there
[08:35] <rvba> Okay then.
[08:44] <basicer> Also, I dont know if this is fixed or not, but it took me like 4 hours to figure out.
[08:44] <basicer> If you public IPs for your nodes, the deb package cache will reject you, and nothing will work T.T
[08:46] <bigjools> you what?
[08:46] <basicer> you use public IPs for your nodes.
[09:27] <rvba> bigjools: you didn't vote on https://code.launchpad.net/~rvb/maas/api-anchors/+merge/212997
[09:28] <bigjools> rvba: yeah sorry I've not really looked at it in detail
[09:28] <rvba> Okay, no worrie.
[09:28] <rvba> worries*
[09:28] <rvba> Maybe jtv will be willing to review it… ?
[09:28] <jtv> ?
[09:29] <rvba> The anchor branch.  See above.
[09:29] <jtv> Yes I would.
[09:29] <rvba> Ta.
[09:42] <jtv> rvba: reviewed
[09:42] <rvba> jtv: thanks
[09:59] <jtv> bigjools: I filed two new cards — for updating the import-pxe-files manpage, and for making it clear that those old shell import config files are obsolete.
[09:59] <jtv> We can handle the latter from the upgrade hook.  No packaging changes needed.
[09:59] <bigjools> jtv: right!  thanks
[10:00] <bigjools> of course!
[10:03] <jtv> I'm going to replace that awkward boot_walk() with its callback parameter with a generator.
[10:16] <jtv> rvba: are you working on labels in the new import script?
[10:16] <jtv> Because I'd like to throw boot_walk out the window.  It's clearer as a generator.
[10:16] <jtv> No more nested callbacks!
[10:17] <rvba> jtv: I'll resume my work on that this afternoon.  Basically testing Oleg's branch.
[10:17] <jtv> This means I'll have to read his email, doesn't it?
[10:18] <rvba> jtv: just have a look at his branch to see if it clashes with want you intend to do.  It's tiny.
[10:18] <jtv> Ah good.
[10:19] <jtv> Yup, there will be conflicts.  But nothing serious.
[10:33] <rvba> jtv: the daily package failed to build: https://launchpadlibrarian.net/170842514/buildlog_ubuntu-trusty-i386.maas_1.5%2Bbzr2153%2B2184%2B254~ppa0~ubuntu14.04.1_FAILEDTOBUILD.txt.gz
[10:33] <jtv> Blast.
[10:33] <rvba> Looks related to your recent changes.
[10:33] <jtv> It was "uploading"...
[10:34] <jtv> Actually, it says "successful build."
[10:34] <jtv> Weird.
[10:34] <allenap> rvba: Have you seen the maas_longpoll problem before?
[10:35] <rvba> allenap: Are you referring to the discussion in #juju-dev?
[10:35] <allenap> rvba: Yeah.
[10:35] <rvba> No, I don't think I've seen this before.
[10:37] <jtv> Ahhh, setup.py still mentions the ephemerals script!
[10:37] <jtv> New branch...
[10:42] <rvba> jtv: didn't 'make package' catch that?
[10:42] <jtv> I have no idea why, but we got a "Build successful" — followed by this error.
[10:42] <rvba> I wonder if running 'make package' shouldn't be part of the landing process as well.
[10:43] <jtv> Yes, now that we have it, we ought to use it.
[10:43] <jtv> Although there are practical problems.
[10:43] <jtv> Sometimes a branch change is paired up with a packaging change, and they need to land in lockstep.
[10:44] <allenap> In that it writes to it’s parent directory? (Whoever though that was a good idea when developing deb tools was on meth.)
[10:44] <rvba> You can always land things manually in this case.
[10:46] <allenap> rvba: Do you understand what’s happening in that paste from vladk?
[10:46] <jtv> Small & easy branch for review!  Cheap karma!  https://code.launchpad.net/~jtv/maas/remove-ephemerals-script-from-setup/+merge/213017
[10:47] <rvba> allenap: No really, could "invoke-rc.d: policy-rc.d denied execution of restart." be the cause of this mess?
[10:48] <rvba> jtv: approved
[10:48] <jtv> Thanks.
[12:36] <melmoth> hola ! I have a customet that tells me "when i add-unit nova-compute, a box is installed, but no nova-compute charm is never installed"
[12:37] <melmoth> i was expecting to see some error in /var/log/cloud-init-outpout.log but there is no such file
[12:37] <melmoth> there is a /var/log/cloud-init.log though https://pastebin.canonical.com/107252/
[12:37] <melmoth> but i dont see any obvious error to my eyes.. where should i investigate ?
[12:38] <smoser> basicer, its not really trivial to change the way curtin changes filesystem.
[12:39] <smoser> what did you want to do ?
[14:05] <roaksoax> rbasak: cool! thanks for taking care of that
[14:52] <dimitern> gmb, https://bugs.launchpad.net/maas/+bug/1297814 that's the bug
[14:53] <gmb> dimitern: Cool, thanks.
[16:23] <perrito666> rvba: hi, have a moment for a question regarding gomaasapi.testservice?
[16:26] <rvba> perrito666: go ahead
[16:27] <perrito666> rvba: I am trying to make the testserver have /networks
[16:27] <perrito666> I registered the function to handle /api/<version>/networks/
[16:27] <perrito666> yet I get bad request whey I run the test I wrote
[16:27] <perrito666> before I start debugging my own code :)
[16:27] <perrito666> is there any step I am missing to register a new api endpoint?
[16:27] <rvba> perrito666: do you have a diff I could look at?
[16:28] <perrito666> cetainly
[16:29] <perrito666> rvba: http://pastebin.ubuntu.com/7163586/
[16:39] <basicer> smoser: Well my machines have four disks;  I would like to either put them in raid; or set up a btrfs filesystem that uses all 4.
[16:40] <rvba> perrito666: what's the url of the request that generates a 400 error?
[16:44] <perrito666> rvba: I am trying to igure out how to get that :) since I am using maasObj.CallGet("networks", params)
[16:44] <perrito666> will get back t you when I do
[16:45] <rvba> perrito666: I think the problem is that, if you have params (and I assume you do), "/api/%s/networks/" isn't going to catch the request.
[16:45] <perrito666> rvba: I thought they where not considered in the url matching
[16:45]  * perrito666 is djang biased
[16:46] <perrito666> rvba: tx
[16:46] <rvba> perrito666: hum, you might be right, looks like we're comparing that to the 'path' part of the URL
[16:47] <mgz> perrito666: you mean you're written in python too?
[16:48] <perrito666> mgz: yes, I am poorly templated tho
[16:53] <rvba> perrito666: is networksHandler() being called at all?
[16:57] <perrito666> rvba: apparently not
[16:58] <perrito666> that i wh I was wondering if I was missing a step ther
[17:00] <rvba> perrito666: I don't see anything obviously wrong.
[17:00] <perrito666> rvba: Ill keep looking into it, perhaps I can get the fake server to output all requests to stdout
[17:01] <rvba> Yeah, that would be a start.
[17:30] <perrito666> rvba: duh, call get is calling http://127.0.0.1:41401/api/1.0/nodes/test1/?node=test1&op=networks
[20:02] <Valduare> how many physical servers do I need to setup an ubuntu cloud, maas, juju, openstack etc
[20:03] <roadmr> Valduare: simplistically, I think 10: 1 for maas, 1 for the juju bootstrap node, and 8 for the services comprising openstack (I count 8 of them)
[20:04] <Valduare> 10 physical servers?
[20:05] <roadmr> Valduare: right. I think you can put several services in the same node to cut down on number of servers needed
[20:06] <Valduare> Right now I have one little mini itx board running 14 vm’s all setup manually lol
[20:06] <Valduare> cant afford 10 physical servers
[20:06] <roadmr> Valduare: (that's why I said "simplistically" - if you have enough hardware, just slap maas on one node, install juju on that one, and juju deploy all the openstack services, you don't need to configure anything else)
[20:07] <roadmr> Valduare: haha well I think you can have maas managing virtual machines, then you'd only need 1 server :D
[20:07] <Valduare> I have all of my vm’s stored on a freenas box serving iscsi atm
[20:08] <Valduare> and an esxi host on a gigabyte gae-350n mobo with 16 gigs of ram
[20:23] <Valduare> http://insights.ubuntu.com/resources/tutorials/interested-in-maas-and-juju-heres-how-to-try-it-in-a-vm/ interesting