[07:53] <jtv> The CI has been seeing import failures because /usr/lib/syslinux/pxelinux.0 did not exist... missing dependency?
[07:59] <rvba> jtv: the maas-test CI job is failing because it expects a 1.6 or trunk-based package and all we have in Utopic is 1.5.
[08:01] <jtv> Can we fix that?
[08:03] <rvba> As soon as 1.6 will be published in Trusty, the problem will go away.  The best fix, I think, is to change the CI job so that it can take a PPA argument and use the MAAS package from that PPA.
[08:04] <rvba> This way we can get the CI job to use the package that is our "target package" instead of using whatever is in the archive at the time.
[08:08] <rvba> jtv: would you mind having another look at https://code.launchpad.net/~rvb/maas/event-model/+merge/227156 ?  The code has changed significantly after my discussion with Julian but I've addressed your comments that where still valid after I changed the code.
[08:08] <jtv> OK, having a look.
[08:09] <rvba> Ta.
[09:24] <rvba> allenap: reviewed the 'fascist' branch ;)
[09:26] <allenap> rvba: Thanks!
[10:17] <rvba> allenap: jtv: any idea why the CI is failing with "No module named bson"? http://paste.ubuntu.com/7829493/
[10:17] <rvba> Did we add the bson dependency recently?
[10:18] <rvba> It seems to me we've been using bson for quite some time.
[10:21] <rvba> Hum, looks related map_enum being moved to provisioninserver…
[10:50] <allenap> rvba: Gosh, no. I’ve not changed anything in that area recently, I think.
[11:07] <jtv> rvba: looks like newell used the same decoders as allenap, but this time it led to trouble...
[11:09] <jtv> Why does a function called node_exists need bson..?
[11:10] <jtv> Ah, so it queries the API for a node and, probably just for belt-and-braces, decodes the response from either json or bson as appropriate.
[11:13] <jtv> I could imagine this adding the bson dependency to a package that didn't need it before, but isn't this one of those cases where we have all our packages' dependencies installed?
[11:13] <jtv> Pardon my ambiguity.
[11:13] <jtv> "Isn't the failure in a situation where bson would be installed even if it's a dependency for a _different_ maas package?"
[11:15] <allenap> Yeah. It’s odd. There are two different bson packages though, and we need one in particular. I wonder if it’s picking up the wrong one…
[11:16] <rvba> I /think/ the problem is not in the package but in how the CI builds the package.
[11:17] <jtv> Ah, mixed install mechanisms again...
[12:08] <rvba> allenap: I've got a weird test failure that seem related to twisted getting in the way…
[12:09] <rvba> allenap: the pserv tests fail with http://paste.ubuntu.com/7829947/
[12:09] <rvba> (On my event-rpc-utility branch)
[12:10] <rvba> allenap: what's weird is that the tests I added in this branch pass in isolation… but fail when running the complete test suite.
[12:16] <rvba> allenap: I suppose I'm doing something wrong here: I'm importing "from maasserver.testing.factory import factory" from inside the pserv code.  But how can I initiate my objects otherwise?
[12:23] <allenap> rvba: You can’t and you shouldn’t.
[12:24] <allenap> rvba: Verify that the call is being made correctly according to the specifications in p.rpc.region, but have a stub/fake response.
[12:25] <rvba> allenap: right, I was creating real nodes but this is already a test that uses a fake client so I guess I don't need real nodes…
[12:26] <allenap> rvba: Nah :)
[12:26] <rvba> allenap: what's funny is that the tests as they are now pass in isolation.
[12:29] <allenap> rvba: Perhaps because they're not running using a Django-derived test case, or using Django’s runner; those do some bookkeeping and tidying-up with regards to the database and stuff.
[12:30] <allenap> rvba:
[12:30] <allenap> rvba: If you have a moment could you look at my additions to https://code.launchpad.net/~allenap/maas/rpc-call-list-operating-systems/+merge/227117?
[12:30] <allenap> then I’ll be 100% on power control :)
[12:31] <rvba> allenap: cool :).  I'll have a look at your branch in a sec.
[13:07] <allenap> rvba: Thanks for that review. Here’s the first for power: https://code.launchpad.net/~allenap/maas/rpc-power-remove-celery-vars/+merge/227550
[13:07] <rvba> allenap: \o/
[13:27] <blake_r> allenap: is the rpc for operating systems wired in?
[13:35] <allenap> blake_r: Not 100%. Are you blocked?
[13:36] <blake_r> allenap: one the license-key-view and ubuntu-release-simplestreams
[13:37] <allenap> blake_r: Okay. I’m going to juggle finishing that with rvba’s demands; he can hassle me in my timezone :)
[13:37]  * allenap goes to collect kids from school.
[15:25] <jseutter> I have some computers that stop at the grub boot prompt after installing with maas.  A third computer with the same hardware boots just fine.  Does anyone know where I should look for issues?
[15:28] <bigjools> jseutter: can you photo the screen and paste it so we can see?
[15:28] <bigjools> rvba: what say you to this? https://code.launchpad.net/~jason-hobbs/maas/allow-hostname-change-while-allocated/+merge/227372
[15:29] <jseutter> bigjools: yes, I'll do that in a few
[15:31] <rvba> bigjools: looks like we had very good reasons to prevent the host from being renamed while its in use… I'm trying to see if the assumptions on which the original code was based have changed…
[15:32] <bigjools> rvba: my thoughts too
[15:32] <bigjools> juju snafus
[15:32] <rvba> Yeah
[15:34] <rvba> jhobbs: Hi there.  Looking at lp:~jason-hobbs/maas/allow-hostname-change-while-allocated, wonder why you seem confident that Juju won't be utterly confused by a node changing its name in flight?
[15:34] <jhobbs> rvba: i'm not at all confident
[15:34] <rvba> jhobbs: Then you like to gamble :)
[15:34] <jhobbs> rvba: but why would you change a node's hostname if it will confuse juju?
[15:35] <jhobbs> rvba: if you run a DNS server, you know changing hostname config for running systems might break them, so you don't do it
[15:35] <bigjools> it could also confuse the node
[15:35] <bigjools> I suppose we can allow people to footgun and let them pick up the toes later
[15:39] <jhobbs> bigjools: rvba: well the use case here is 1) acquire node 2) set hostname 3) start node
[15:39] <rvba> jhobbs: MAAS sort of works on the contract that once a node is allocated, it's under someone else's control.  I think this also means that MAAS sorts of guarantees that the information about the node (most notably DNS info) won't be changed.
[15:39] <jhobbs> rvba: is that how other cloud providers work?
[15:40] <rvba> jhobbs: I understand that, but I don't think we should remove the restriction in question before we clearly distinguish between acquired+off and acquired+started
[15:40] <jhobbs> i setup a digital ocean system recently; i started the system, had it a couple of days, then configured dns for it
[15:43] <rvba> jhobbs: trying to work out juju's exact expectations now…
[15:44] <jhobbs> rvba: juju isn't the only consumer though
[15:44] <rvba> jhobbs: indeed.  But it's an important one.
[15:44] <rvba> jhobbs: this restriction exists mostly because of Juju.
[15:44] <jhobbs> rvba: you can always just not change your hostnames if you're running juju - it only happens if someone asks it to, not automatically
[15:46] <rvba> jhobbs: true
[15:46] <jhobbs> rvba: is acquired+stopped vs acquired+start tracking something being worked on already?
[15:47] <rvba> jhobbs: no
[15:48] <rvba> jhobbs: I guess we want 3 states: acquired (i.e. not started), deploying (being installed) and deployed (acquired+started=in use)
[15:49] <rvba> jhobbs: adding the distinction deploying vs deployed is part of the robustness work.
[15:50] <jhobbs> do deploying and deployed apply to commissioning also?
[15:50] <rvba> Not really, 'commissioning' already is an "in progress" state.
[15:52] <jseutter> bigjools: pic of grub prompt here: http://imgur.com/Kdaq64G
[15:52] <jseutter> bigjools: I'm surprised you're awake..
[15:52] <bigjools> jseutter: me too :)
[15:52] <bigjools> jseutter: landed in UK this morning
[15:53] <jseutter> bigjools: ah!
[15:53] <bigjools> jseutter: I am afraid I have NFI what is wrong there.  Perhaps one of jhobbs, blake_r or roaksoax_ might
[15:54] <jseutter> bigjools: ok, well thanks for having a look.  :)  In the meantime I'll dig through the bios on these machines and look for differences.
[15:55] <jhobbs> i've never seen that error
[15:55] <jhobbs> "attempt to read or write outside of disk `hd0`
[15:55] <bigjools> jseutter: did you install with curtin or d-i?
[15:56] <jseutter> d-i.   I might be misremembering, but I think curtin just black-screened for several hours until I gave up.
[15:56] <bigjools> ummm
[15:57] <bigjools> is the disk partitioned already?
[15:57] <jseutter> bigjools: yes
[15:57] <bigjools> does it have any of them marked for raid?
[15:59] <blake_r> jseutter: this might help you
[15:59] <blake_r> jseutter: http://askubuntu.com/questions/397485/what-to-do-when-i-get-an-attempt-to-read-or-write-outside-of-disk-hd0-error
[15:59] <jseutter> bigjools: there are several disks in the raid, configured as one virtual disk on the raid card.  What do you mean by marked for raid?
[16:00] <bigjools> jseutter: I think it's a bug in the installer, I have vage recollections of seeing this even outside of maas once
[16:00] <bigjools> vague, even
[16:02] <jseutter> bigjools: hm, I'm just looking at the system that booted successfully, and the drac raid section says there are no disks in the system.  I have somewhere to start digging
[16:02] <mthaddon> I'm trying out MAAS on a machine. It's a region and cluster controller (trusty) and I have a VM I'm trying to add as a node. It's currently stuck in "Commissioning" status and if I try to either commission or start it from /MAAS/nodes/ I get: The action "..." could not be performed on 1 node because its state does not allow that action.
[16:02] <mthaddon> any ideas what I'm missing? I don't see anything useful in logs in /var/log/maas
[16:02] <jseutter> blake_r: thanks
[16:03] <bigjools> mthaddon: two things to check
[16:03] <bigjools> 1. did you define the power details correctly?
[16:03] <bigjools> 2. is the cluster controller celeryd running?
[16:03] <bigjools> damn, we need a faq
[16:03] <bigjools> and hi mthaddon btw :)
[16:04] <mthaddon> bigjools: o/
[16:04] <mthaddon> bigjools: power address is "qemu:///system" and I've confirmed I can run "virsh --connect qemu:///system list" as the maas user
[16:05] <mthaddon> bigjools: power ID is "test" and the name of the virsh instance from virsh list --all is "test"
[16:05] <bigjools> mthaddon: did you follow this http://maas.ubuntu.com/docs/nodes.html#virtual-machine-nodes
[16:05] <mthaddon> I did, yep
[16:05] <bigjools> col
[16:05] <bigjools> cool
[16:06] <bigjools> blast this keyboard, it's going in the bin
[16:06] <mthaddon> I see celery processes running
[16:07] <bigjools> if you look in its log /var/log/maas/celery.log, do you see a line with power_on around the time you added the node?
[16:07] <mthaddon> bigjools: http://paste.ubuntu.com/7831026/
[16:08] <bigjools> mthaddon: aha
[16:08] <bigjools> sadly, I think you're using an old version that lacks debugging info
[16:08] <mthaddon> bigjools: an old version? this was a clean install over the weekend!
[16:08] <bigjools> of which maas version?
[16:09] <mthaddon> well, of trusty - maas appears to be 1.5.2+bzr2282-0ubuntu0.2
[16:09] <bigjools> ok
[16:09] <mthaddon> is that "old"?
[16:09] <bigjools> ummmmm you can get past this by "powering up" the VM manually for now
[16:10] <bigjools> not massively, but I am surprised the task logging isn't working :(
[16:10] <mthaddon> presumably I'd need to tell it to connect to the MAAS cluster somehow? I'm not doing DHCP or DNS via MAAS
[16:10] <bigjools> and then you'll have to try and re-create what the power template is doing to start the node up to work out what's wrong
[16:11] <bigjools> if you're not managing dhcp, then presumably you've configured another DHCP with the next-server pointing at maas?
[16:11] <mthaddon> I haven't - if that's the next step, sounds like I need to do that
[16:12] <bigjools> yeah
[16:13] <bigjools> mthaddon: http://maas.ubuntu.com/docs/configure.html#manual-dhcp-configuration
[16:14] <mthaddon> k, thx