[00:50] <mup> Bug #1547275 opened: [2.0] Can't add a node with power parameters <MAAS:Confirmed> <https://launchpad.net/bugs/1547275>
[00:50] <mup> Bug #1547276 opened: [2.0] "No rack controllers can access the BMC of node: <node>" with wake onlan <MAAS:New> <https://launchpad.net/bugs/1547276>
[00:56] <mup> Bug #1547275 changed: [2.0] Can't add a node with power parameters <MAAS:Confirmed> <https://launchpad.net/bugs/1547275>
[00:56] <mup> Bug #1547276 changed: [2.0] "No rack controllers can access the BMC of node: <node>" with wake onlan <MAAS:New> <https://launchpad.net/bugs/1547276>
[01:02] <mup> Bug #1547275 opened: [2.0] Can't add a node with power parameters <MAAS:Confirmed> <https://launchpad.net/bugs/1547275>
[01:02] <mup> Bug #1547276 opened: [2.0] "No rack controllers can access the BMC of node: <node>" with wake onlan <MAAS:New> <https://launchpad.net/bugs/1547276>
[01:03] <mup> Bug #1547277 opened: [2.0] MAAS prevents adding a machine when it cannot power manage it. <MAAS:New> <https://launchpad.net/bugs/1547277>
[01:18] <mup> Bug #1547277 changed: [2.0] MAAS prevents adding a machine when it cannot power manage it. <MAAS:New> <https://launchpad.net/bugs/1547277>
[01:21] <mup> Bug #1547277 opened: [2.0] MAAS prevents adding a machine when it cannot power manage it. <MAAS:New> <https://launchpad.net/bugs/1547277>
[03:15] <mup> Bug #1547311 opened: Installing MAAS in Trusty fails to restart apache2 (traceback about the maas user when restarting apache2) <amd64> <apport-bug> <trusty> <uec-images> <maas (Ubuntu):New> <https://launchpad.net/bugs/1547311>
[03:51] <mup> Bug #1547313 opened: newly enlisted nodes have no power type set. <MAAS:New> <https://launchpad.net/bugs/1547313>
[11:21] <maciek> hi all, how can I get maas-image-builder on ubunut 14.04 lts?
[11:26] <maciek> according to docs: http://maas.ubuntu.com/docs/os-support.html#maas-image-builder, but: http://pastebin.com/xj3kSnVt
[11:46] <roaksoax> maciek: maas-image-builder only supports centos. Centos is now vailable in via the 'Images' tabs
[13:03] <Razva> any idea if MAAS + Autopilot will create a NAT for the LAN nic, or should I manually create it?
[13:10] <maciek> roaksoax: how about debian? can I make debian image by myself (even manually)?
[13:23] <kiko> maciek, you should be able to
[13:23] <kiko> maciek, I'm not entirely sure how the Ubuntu cloud images are built (and how they are converted to curtin format) but blake_r and smoser do
[13:23] <kiko> s/do/know
[13:24] <Razva> any idea if MAAS + Autopilot will create a NAT for the LAN nic, or should I manually create it?
[13:26] <kiko> Razva, hmm, it's a good question
[13:26] <kiko> Razva, I assume maas+autopilot takes care of everything
[13:26] <kiko> I know Beret would know
[13:28] <Razva> http://www.ubuntu.com/download/cloud/install-openstack-with-autopilot < this documentation is so...limited
[13:29] <Razva> any other link to some decent documentation...?
[13:30] <kiko> https://help.landscape.canonical.com/
[13:30] <kiko> https://insights.ubuntu.com/2015/04/10/maas-network-layouts-for-the-landscape-autopilot/
[13:32] <Razva> yeah it seems that you first need to create the lan IP, right?
[14:50] <smoser> maciek, i've not got debian images, but it wouldnt be terribly difficult.
[14:50] <smoser> the thing you'd want to model it after is the maas-images code (lp:maas-images) that creates centos images.
[15:14] <haasn> Trying to deploy Ubuntu 16.04 with MAAS fails because it tries resolving its apt mirrors to IPv6 before IPv4
[15:14] <haasn> And then it tries accessing this IPv6 address via the configured apt http proxy
[15:15] <haasn> Which then sends back a 503 because it has no IPv6-capable internet connection
[16:59] <smoser> haasn, you still around ?
[16:59] <smoser> is that new ?
[17:16] <smoser> haasn, i've raised that internally.
[17:22] <Bofu2U> Any ideas what would cause a 503 error on apt-get update only on like... 40-50% of the repos? Provisioning node (maas headnode) updates fine, others go through it as the proxy
[17:22] <smoser> Bofu2U, haasn raised this http://irclogs.ubuntu.com/2016/02/19/%23maas.html#t15:14
[17:22] <smoser> and i have raised it internal (Canonical) is, so hopefully its being worked.
[17:23] <smoser> i raised in the past 5 minutes.
[17:23] <haasn> smoser: I'm back now
[17:23] <Bofu2U> innnteresting
[17:24] <Bofu2U> haasn: I wonder if just sysctl disabling ipv6 would fix it
[17:24] <smoser> on the maas proxy host
[17:25] <smoser> so it doesn't get a ipv6 address when looking up?
[17:25] <Bofu2U> rgr
[17:25] <smoser> i'm not sure what changed though
[17:26] <Bofu2U> doesn't look like that did it
[17:26] <Bofu2U> how did you link that to the ipv6 resolution?
[17:28] <haasn> My issue is not maas-related actually
[17:28] <haasn> (I think)
[17:37] <Bofu2U> oh
[17:37] <Bofu2U> I'm assuming mine is directly related to the maas-proxy
[17:37] <Bofu2U> headnode is perfectly fine, provisioned machines aren't
[17:45] <smoser> Bofu2U, the provisioned systems use the maas region controller (or maybe cluster controller)
[17:45] <smoser> as their proxy
[17:45] <Bofu2U> yea
[17:45] <smoser> so in searching for "what changed"...
[17:45] <smoser> you likely got a libnss3 update on your maas system
[17:45] <smoser> delivered via security updates for CVE-2016-1938
[18:15] <haasn> here's the weird thing on my end
[18:15] <haasn> I have two nodes running as VMs on the same host, using the same networking setup, using the same squid-deb-proxy
[18:15] <haasn> I deploy one as ubuntu 14.04 and one as ubuntu 16.04
[18:15] <haasn> And the 14.04 one works and the 16.04 one does not
[18:16] <haasn> Aren't they just passing the URLs verbatim to the squid proxy?!
[18:18] <haasn> Hmm, actually no, the 14.04 is still ‘deploying’. I misread it for ‘deployed’
[18:18] <haasn> Seems it's stuck
[18:18] <haasn> And it can't `apt update` :(
[18:37] <smoser> haasn, i'm not sure quite what caused the change
[18:38] <smoser> but i do believe that you can fix it with adding 'dns_v4_first on' to your appropriate squid.conf
[18:38] <haasn> I remember trying u16.04 in the past with the same result, but then I went back to 14.04 again and it worked since then
[18:38] <smoser> if that squid.conf is from maas-proxy, then it is /usr/share/maas/maas-proxy.conf
[18:39] <smoser> Bofu2U, ^
[18:40] <haasn> It's a custom squid-deb-proxy, but I'll give it a shot
[18:40] <haasn> At any rate, after adding that and restarting the server I can get an answer for curl -x mirror:8000 archive.ubuntu.com again
[18:44] <smoser> haasn, so my experience (which was also a custom squid-deb-proxy)
[18:45] <smoser> was that yesterday, squid would prefer ipv4 addresses when it resolved ip addresses.
[18:45] <smoser> but today, it is picking ipv6
[18:45] <smoser> and it has no ipv6 connectivity
[18:45] <smoser> so... that isn't going to work
[18:46] <haasn> smoser: the dns change seems to have fixed it for me
[19:06] <smoser> haasn, Bofu2U i ipened bug https://bugs.launchpad.net/ubuntu/+source/squid-deb-proxy/+bug/1547640
[19:08] <mup> Bug #1547640 opened: proxy tries ipv6 and gets 503 when no ipv6 routes <MAAS:New> <squid (Ubuntu):New> <squid-deb-proxy (Ubuntu):New> <https://launchpad.net/bugs/1547640>
[19:34] <haasn> Hmm, fixed the issue but I still can't deploy 16.04. The machine seems to install fine (install log “Installation complete”) but it doesn't reboot or continue the installation
[19:34] <haasn> I rebooted the node manually and nothing changed
[20:03] <haasn> Heh, I hopped on a remote shell and looked at what the machine was doing
[20:04] <haasn> Stuck on 100% CPU in a “booting...”.. probably executing NOOPs for the rest of its life :p
[20:38] <mup> Bug #1547661 opened: ValidationError for non present architectures when adding a Chassis <MAAS:New> <https://launchpad.net/bugs/1547661>
[21:34] <fritchie> to commission a node in MAAS does MAAS need to be able to control the power?
[21:36] <haasn> Hmm, I rebooted my maas server and now the HTTPd is not running (nothing is listening on port 80), what's the service called?
[21:38] <haasn> Hmm, /usr/share/maas/maas-http.conf is missing apparently
[21:39] <haasn> Ah, I figured it out. When installed ntp, it removed all of the maas packages again..
[21:39] <haasn> Because ntp pulled in some library that maas was incompatible with (yet again)
[21:39] <haasn> It seems basically every `apt upgrade` uninstalls maas
[21:42] <haasn> Looks like the culprit is maas-region-controller depending on python-django < 1.7, but python-django-1.7.9 being selected while upgrading
[21:46] <haasn> echo "python-django hold" | dpkg --set-selections # work-around
[22:30] <fritchie> how can I determine exactly why a node failed commissioning?