[23:02] <bigjools> roaksoax: did you see https://code.launchpad.net/~allenap/maas/remove-ipmi-optimisation/+merge/160146
[23:18] <roaksoax> bigjools: yeah... did you see this: http://pastebin.ubuntu.com/5594094/
[23:18] <roaksoax> bigjools: i just upgraded a machine from quantal t raring and seeing that error
[23:18] <bigjools> looking
[23:19] <bigjools> roaksoax: is that with the latest power fix?
[23:19] <roaksoax> bigjools: i believe so yes
[23:19] <bigjools> they tested it in the lab
[23:19] <bigjools> and it was ok
[23:20] <bigjools> so - confused
[23:20] <roaksoax> i'm gonna revert it and see what happens
[23:20] <bigjools> where are you running that?
[23:21] <roaksoax> bigjools: this is virsh btw, not ipmi
[23:21] <roaksoax> in a lab
[23:22] <roaksoax> bigjools: maybe this is the issue: http://bazaar.launchpad.net/~maas-maintainers/maas/trunk/revision/1456
[23:22] <bigjools> roaksoax: why is ipmi set as the power type for a VM?
[23:22] <roaksoax> bigjools: is not ipmi, it is virsh
[23:23] <bigjools> roaksoax: that revno is not a problem, it is doing the right thing
[23:23] <bigjools> so you have a failure in the virsh script
[23:23] <bigjools> it needs to be debugged
[23:23] <roaksoax> bigjools: yeah the virsh script hasn't really changed, so it shouldn't fail
[23:23] <bigjools> sorry - I didn't realise you were talking about virsh all of a sudden :)
[23:23] <roaksoax> hehe
[23:23] <bigjools> roaksoax: it was probably failing before and we didn't know
[23:23] <roaksoax> yeah this is our virtual-maas
[23:23] <bigjools> now we know
[23:23] <bigjools> roaksoax: could just be exit status on script
[23:24] <roaksoax> bigjools: i'm thinking that it might be not having access to virsh
[23:24] <roaksoax> that's what I'm thinking
[23:24] <bigjools> the same code works with ipmi and friends
[23:24] <bigjools> we never tested virsh very much as it's not "metal" :)
[23:24] <bigjools> and now you're using it a lot more
[23:25] <roaksoax> bigjools: ok apparently is virsh issue
[23:25] <bigjools> phew
[23:25] <roaksoax> i mean not having permission for virsh
[23:25] <roaksoax> but that's strange since there's a sudoers file for it
[23:26] <bigjools> roaksoax: we could do with more info printed in that error
[23:26] <roaksoax> indeed
[23:29] <roaksoax> bigjools: http://paste.ubuntu.com/5594116/ --> tha obviously doesn't fail - this does: http://pastebin.ubuntu.com/5594122/
[23:29] <roaksoax> bigjools: so probably permissions
[23:30] <bigjools> roaksoax: agreed
[23:34] <roaksoax> i'll investigate tomorrow im off now
[23:35] <bigjools> roaksoax: cheers
[23:35] <mwhudson> bigjools: good morning
[23:35] <bigjools> wotcha mwhudson
[23:36] <mwhudson> bigjools: i installed maas on calxeda the other day
[23:36] <mwhudson> bigjools: mostly it worked fine but i got a bit confused about a few things
[23:37] <bigjools> understandable :)
[23:37] <mwhudson> bigjools: the biggest one was that juju defaults to asking for an amd64 node for bootstrap
[23:37] <mwhudson> and it took me a long time to figure out this was why it wasn't getting an instance
[23:38] <bigjools> that's not very nice if it, why should it care I wonder
[23:38] <bigjools> of it*
[23:38] <bigjools> which juju?
[23:38] <mwhudson> py
[23:38] <bigjools> weird then
[23:38] <bigjools> does the Go version work on ARM? :)
[23:39] <mwhudson> i ended up adding logging statements to the maas api server to print out the arguments...
[23:39] <mwhudson> which was a bit sad-making
[23:39] <mwhudson> bigjools: i don't think so
[23:39] <bigjools> :/
[23:40] <mwhudson> bigjools: the other thing i wanted to bug you about was that ages ago you said that maas would soon gain the ability to splat a tarball onto disk rather than running debian-installer
[23:40] <mwhudson> bigjools: did that happen?
[23:40] <bigjools> mwhudson: it's WIP.  roaksoax and smoser are working on the installer, the MAAS changes are done though.
[23:41] <mwhudson> ok
[23:41] <mwhudson> is there a blueprint i can subscribe to or anything?
[23:43] <bigjools> hmmm not on my list