[08:22] <mup> Bug #1579655 opened: Feature Request: Lock nodes to avoid accidental de-commission / release actions <feature> <lock> <node> <password> <MAAS:New> <https://launchpad.net/bugs/1579655>
[08:31] <mup> Bug #1579655 changed: Feature Request: Lock nodes to avoid accidental de-commission / release actions <feature> <lock> <node> <password> <MAAS:New> <https://launchpad.net/bugs/1579655>
[08:40] <mup> Bug #1579655 opened: Feature Request: Lock nodes to avoid accidental de-commission / release actions <feature> <lock> <node> <password> <MAAS:New> <https://launchpad.net/bugs/1579655>
[11:40] <mup> Bug #1579729 opened: DHCP Snippets: The toggle buttons cannot be deactivated <design> <ui> <MAAS:New> <https://launchpad.net/bugs/1579729>
[12:23] <neiljerram> Would you expect a MAAS controller on Trusty to be able to deploy a Xenial distro onto a node?
[12:46] <brendand> neiljerram, yes
[12:47] <brendand> neiljerram, what version to you have?
[12:47] <neiljerram> brendand, Thanks.
[12:47] <neiljerram> brendand, I have MAAS 1.9.1.
[12:47] <brendand> neiljerram, for sure then
[12:47] <brendand> neiljerram, let us know if you have any problems
[12:48] <neiljerram> brendand, I've been seeing the boot failure that is described at https://bugs.launchpad.net/maas/+bug/1577838
[12:49] <neiljerram> brendand, I wondered if it might be a problem with the Xenial image, so have been trying this intermittently over the last few weeks.
[12:49] <brendand> neiljerram, could be something unusual to that piece of hw
[12:50] <neiljerram> brendand, It's a vSphere VM.
[12:50] <neiljerram> brendand, I mean, both the MAAS controller and the target node are vSphere VMs.
[12:51] <brendand> ok
[12:51] <neiljerram> brendand, But I also have some baremetal in the same MAAS cluster, and Xenial deployment failed on those too.  In those cases I didn't yet go to their console, to investigate if it was the same problem.
[12:52] <neiljerram> brendand, Is MAAS with vSphere VMs a common setup?
[12:53] <brendand> neiljerram, not that i'm aware of
[12:54] <neiljerram> neiljerram, OK, so perhaps my next step should be to take a closer look at what goes wrong when I try to deploy Xenial on one of the baremetal machines.
[12:59] <neiljerram> brendand, Thanks for your help - you've eliminated one of the main uncertainties that I had!
[13:32] <mup> Bug #1579150 changed: MAAS 1.8 - can't provision nodes <MAAS:Invalid> <https://launchpad.net/bugs/1579150>
[13:32] <mup> Bug #1579655 changed: Feature Request: Lock nodes to avoid accidental de-commission / release actions <feature> <lock> <node> <password> <MAAS:New> <https://launchpad.net/bugs/1579655>
[13:32] <mup> Bug #1579758 opened: No advanced networking for non Ubuntu OS <MAAS:New> <https://launchpad.net/bugs/1579758>
[14:02] <mup> Bug #1579758 changed: No advanced networking for non Ubuntu OS <MAAS:New> <https://launchpad.net/bugs/1579758>
[14:04] <roaksoax> neiljerram: please upgrade to 1.9.2
[14:05] <neiljerram> roaksoax, Aha, thanks!  So am I seeing a known problem that 1.9.2 fixes?
[14:08] <roaksoax> neiljerram: due to a change in python-distroinfo MAAS 1.9 is no longer able to commission machines becuase Xenial is not a supported commissioning image in 1.9
[14:09] <neiljerram> neiljerram, And 1.9.2 fixes that?
[14:09] <roaksoax> neiljerram: yes
[14:09] <neiljerram> roaksoax, Great, thanks, I will try that upgrade very soon.
[15:26] <neiljerram> roaksoax, FYI I'm afraid it must be a different problem tripping me up.  After 1.9.2 upgrade I'm still seeing the boot issue that I was seeing before. ("disk/by-path/ip-172.18.203.214:3260-iscsi-iqn.2004-05.com.ubuntu:maas:ephemeral-ubuntu'amd64-hwe-x-xenial-daily-lun-1": Invalid path for Logical Volume ... Gave up waiting for root device)
[15:26] <mup> Bug #1575946 changed: do-release-upgrade failure (trusty->xenial) when squid3 is installed <dist-upgrade> <landscape> <squid3 (Ubuntu):New> <ubuntu-release-upgrader (Ubuntu):New> <https://launchpad.net/bugs/1575946>
[15:35] <roaksoax> neiljerram: try restarting tgtd ?
[15:37] <neiljerram> roaksoax, thanks.  I have two tgt error logs in syslog:
[15:37] <neiljerram> roaksoax, 1. iser_ib_init(3355) Failed to initialize RDMA; load kernel modules?
[15:38] <neiljerram> roaksoax, 2. bs_thread_open(428) failed to create a worker thread, 12 Resource temporarily unavailable
[15:42] <roaksoax> neiljerram: interesting...
[15:43] <roaksoax> doesn't seem like tgt has gotten an update lately that would break that
[15:43] <neiljerram> roaksoax, I just tried modprobe rds_rdma and then restarting again - but no change in those logs
[15:43] <roaksoax> neiljerram: is there anythin in kern.log or syslog or dmesg regarding apparmor ? i wonder if that's related
[15:45] <neiljerram> roaksoax, In the last hour, no, nothing.
[15:46] <roaksoax> ltrager: ^^ why would we have such a failure ?
[20:49] <mup> Bug #1573046 changed: [SRU] 14.04 images not available for commissioning as distro-info --lts now reports xenial <landscape> <sts> <MAAS:Fix Released by andreserl> <maas (Ubuntu):Fix Released> <maas (Ubuntu Trusty):Confirmed> <maas (Ubuntu Wily):Confirmed> <https://launchpad.net/bugs/1573046>
[20:51] <mup> Bug #1579909 opened: [2.0b4] All dynamic range's configure PXE <MAAS:New> <https://launchpad.net/bugs/1579909>
[22:24] <mup> Bug #1579930 opened: maas-clusterd process respawning periodically - init: maas-clusterd main process ended, respawning <oil> <MAAS:New> <https://launchpad.net/bugs/1579930>