[11:23] <rvba> bigjools: fwiw, I just got an AMT node installed using di (Trusty).  Worked fine.  Rebooted all right, I can ssh into the node now…
[11:23] <rvba> bigjools: what was your problem again?
[13:01] <jefferai> When MAAS finishes installing to a machine, should that machine then boot up to a hard disk, or should it continue to pxe boot?
[13:01] <jefferai> because when commissioning is done, the machine is unable to boot off the hard drive
[13:15] <jtv> jefferai: commissioning doesn't install.  The OS gets installed when you allocate the machine.
[13:15] <jtv> Because you get to choose the OS every time you allocate one.
[13:16] <jefferai> oh
[13:16] <jtv> It's possible for commissioning to format the disks, if you want to add a script that does that; but the default commissioning process is non-destructive.
[13:16] <jefferai> So you commission it, which does some stuff; then you allocate it, and then you boot it up ater that
[13:16] <jefferai> and when you allocate it, and then pxe boot after allocation, it runs the install
[13:16] <jefferai> that sound right?
[13:16] <jtv> Yes — and you can have multiple users on the maas that may all allocate machines for themselves.
[13:17] <jtv> So think of commissioned machines as a pool of hardware waiting for someone to come in and grab it for use.
[13:20] <jefferai> I See
[13:20] <jefferai> I gotta say, the documentation doesn't make that very clear :-/
[13:21] <jefferai> Even though it makes total sense
[13:21] <jefferai> Also, even knowing that, I don't see how you allocate nodes :-)
[13:21] <jefferai> at least not on the web; maybe it's cli only
[13:21] <jefferai> ?
[13:22] <jtv> On the web, you can go to a node's page and click "Start node."
[13:22] <jtv> Or, on the nodes listing, you can select a bunch of nodes and start them with a single action.
[13:22] <jefferai> oh, starting allocates
[13:22] <jefferai> I did see that
[13:22] <jtv> There is an unfortunate difference between the API nomenclature and the UI nomenclature.
[13:23] <jtv> In the UI, "Start node" means "allocate this node, fire it up & install it."
[13:23] <jefferai> I see
[13:23] <jtv> In the API, it means "power up this node and let it do whatever its programmed action is, e.g. install it if it's allocated."
[13:23] <jefferai> :-/
[13:23] <jefferai> OK
[13:24] <jefferai> Will keep playing -- thanks!
[13:24] <jtv> A new, more high-level API call is planned, so hopefully we can forget about that difference later.
[13:24] <jtv> Thanks for pointing out the documentation deficiency — I'll make a note that that needs work.
[14:14] <jtv> jefferai: would this documentation change make it clearer? https://code.launchpad.net/~jtv/maas/doc-allocation/+merge/219540
[14:33] <jefferai> jtv: it does, yes. Also it made me realize a part of why I couldn't start up a node: I hadn't set an SSH key
[14:33] <jefferai> Start was always disabled for me
[14:33] <jefferai> so the only thing I could do was commission over and over
[14:33] <jtv> Yeah, conceptual frameworks are the most important part of documentation — and the most easily forgotten one.
[14:34] <jefferai> now to figure out why it's not toggling my vm over virsh :-)
[14:34] <jtv> We fixed a bug for that last week, actually.  Though I thought that had been released...
[14:35] <jefferai> jtv: maas user wasn't added to libvirtd group
[14:36] <jefferai> testing now to see if that's the problem
[14:36] <jefferai> but it prevented the maas user from using virsh via sudo test
[14:36] <jefferai> probably it should be added to libvirtd by default...
[14:37] <jtv> There's also the added complication there that after adding yourself to the group, you need a fresh login.
[14:38] <jtv> gmb: could I perhaps pick on you to review https://code.launchpad.net/~jtv/maas/doc-allocation/+merge/219540 ?  Yes I'm technically off today but couldn't resist.
[14:39] <jefferai> jtv: yeah -- a fresh reboot also seemed to solve my issue with postgres we talked about yesterday
[14:39] <jefferai> seems maas wants rebooting anyways
[14:39] <jefferai> :-)
[14:41] <jtv> Shouldn't really.  :/  I'm trying to pry the postgres thing loose from my memory, but not having much luck.
[14:41] <jefferai> don't worry about it
[14:41] <jefferai> sadly I have now added maas to libvirtd and rebooted, and "sudo -u maas virsh -c qemu:///system list --all" is happy
[14:41] <jefferai> but starting a node from the maas ui isn't
[14:41] <jtv> Oh, the weird "number out of range" exception?
[14:42] <jefferai> jtv: yeah, that
[14:43] <jtv> This may be a matter of tweaking the power type & power parameters just right then...
[14:43] <jefferai> well
[14:43] <jefferai> sudo -u maas virsh -c qemu:///system start base
[14:43] <jefferai> that works
[14:44] <jefferai> it's the same url as in the web ui
[14:44] <jefferai> and same name
[14:44] <jtv> And without the sudo it should work as well, right?
[14:44] <jtv> Oh wait
[14:44] <jtv> Sorry, wasn't all there.
[14:44] <jefferai> unless it's running as a user that isn't maas
[14:44] <jefferai> like www-data
[14:44] <jefferai> doesn't seem so though
[14:44] <jtv> And I guess the reboot made the group membership for maas in virsh take effect...
[14:44] <jefferai> right
[14:45] <jefferai> btw, using maas from trusty repos, is there some newer version I should be using?
[14:45] <jefferai> a ppa?
[14:45] <jtv> There's ppa:maas-maintainers/dailybuilds — which can include the latest breakage, but will also have the latest improvements; and there's the cloud archive.
[14:47] <jtv> See: https://wiki.ubuntu.com/ServerTeam/CloudToolsArchive
[14:47] <jefferai> the cloud archive I think I trid adding but it said it was for precise only
[14:47] <jefferai> so when I hit Start on the node in the web UI, there is nothing in the libvirtd logs
[14:47] <jtv> There's the "cloud archive" and the "cloud tools archive."
[14:47] <jefferai> when I do it from the sudo line above, it's what you'd expect
[14:47] <jefferai> somewhere along the way the command never makes it to libvirtd
[14:48] <jtv> A similar command line _should_ be issued from /etc/maas/templates/power/virsh.template.
[14:48] <jtv> But the version you  have would still have that bug where it got confused about the previous state of the VM (on or off).
[14:48] <jefferai> interesting
[14:48] <jefferai> error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied
[14:48] <jtv> Ooo interesting indeed.
[14:48] <jefferai> so one bug is that when it fails to start the vm, it doesn't note that
[14:48] <jefferai> and makes the web ui think it's been started
[14:49] <jtv> Yeah.  Another thing that's scheduled for improvement: verifying that these things actually happen.
[14:49] <jefferai> so ls -al /var/run/libvirt is what you'd expect
[14:50] <jefferai> which suggests that the wrong user is being used to try to start the machine up
[14:50] <jtv> That would be interesting.
[14:50] <jefferai> I will have the script dump that out
[14:51] <jtv> The command gets run from the provisioning server's celery worker...  Better check that those actually run as the user you expect!
[14:51] <jefferai> ugh
[14:51] <jtv> And now I'm afraid I must leave.  Thanks gmb  for reviewing the  documentation branch.
[14:51] <jefferai> whoami in the script returns "maas"
[14:51] <jefferai> so this is jsut getting weirder
[14:52] <jefferai> unless it's not inheriting its groups properly
[14:52] <jefferai> or something
[14:52] <jtv> Gah.
[14:52] <jtv> BTW note that this gets run on the cluster controller.
[14:52] <jefferai> yeah
[14:52] <jefferai> it's all on one box right now
[14:53] <jtv> Ah
[14:53] <jtv> Maybe it's not the actual socket operation that gets the error.
[14:53] <jtv> Maybe it's something like "I need to read a config file which I'm not allowed to do" or something along those lines.
[14:54] <jtv> Bear in mind that "sudo" keeps using your home directory, but as a different user.
[14:54] <jtv> The maas user doesn't have a home dir, only a GPG home dir in /var/lib/maas.
[14:54] <jtv> And now I'm _really_ leaving.  Will check in later.
[14:56] <jefferai> jtv: heh, ok, thanks  :-)
[14:56] <jefferai> jtv: for when you're back, here's the output of "groups" in the template: maas root
[14:57] <jefferai> and here's the output when I run sudo -u maas groups: maas libvirtd
[14:57] <jefferai> so apparently it's running as the maas user but with a different set of groups -- and this is after a reboot
[15:06] <jefferai> jtv: the only thing I can think of is that the daemon starts as root, which is not in libvirtd; then drops privileges but when it does it doesn't then inherit any new groups
[15:06] <jefferai> and if so, then I would think it shouldn't have "root" as its current groups
[15:06] <jefferai> so I think something is very wrong here
[15:06] <jefferai> either root shouldnt' be in the current groups, or libvirtd should
[15:06] <jefferai> or both
[15:07] <jefferai> I'm going to try adding root to libvirtd
[15:10] <jefferai> jtv: that did it - adding root to libvirtd
[15:10] <jefferai> that's a really weird thing to have to do considering that root is the owner of the socket :-)
[19:38] <jtv> jefferai: turning your notes into a bug report, thanks.  Probably low priority but we have to have a note somewhere.
[21:26] <jefferai> jtv: I'm not sure the libvirt group stuff should be low priority. If you can't take an off-the-shelf maas install and use it with the virsh bits as shown in the installation guide, then something is rather wrong. Especially when it takes listing groups inside of the template to figure out what the problem is