[11:30] Bug #1578595 opened: Deletion validation appears twice === dooferlad_ is now known as dooferlad [13:02] i have no idea what ERROR failed to bootstrap environment: cannot start bootstrap instance: gomaasapi: got error back from server: 404 NOT FOUND (Cluster interface for eth1 only has a dynamic range. Configure a static range, or reconfigure the interface.) means [13:02] well, no - it does seem to be saying to configure a static range, but not sure why [13:34] brendand: did you configure both dynamic/static range in MAAS ? [13:34] roaksoax, no i didn't come across any instruction that asked me to [13:35] brendand: when you configure the NIC for DHCP/DNS< you have both dynamic/static range [13:41] roaksoax, no i didn't come across any instruction that asked me to [13:41] woops [13:42] roaksoax, thanks [14:14] smoser: where did the kernel modules go in the ephemerals? [14:25] ah, to the initramfs! [14:33] dannf, right. and then copied (mount moved) into the root [14:54] hello guys. [14:54] I am having issue with deploying openstack with maas autopilot.. [14:54] File "/usr/lib/python2.7/dist-packages/websocket.py", line 444, in connect\n self.sock.connect((hostname, port))\n File "/usr/lib/python2.7/socket.py", line 224, in meth\n return getattr(self._sock,name)(*args)\nsocket.gaierror: [Errno -2] Name or service not known\n', 'output': ''} [ERROR: 05-05 08:14:07, gui.py:267] A fatal error has occurred: Error deploying Landscape. [14:58] alanv72, looks like maybe a dns or connection error somewhere [14:58] would need more logs and info on your network [14:59] very flat network. all virtual boxes.. maas deploys juju bootstrap and then immediately fails on landscape deployment. [15:00] is landscape deploying on the box that juju bootstrap was just installed? [15:00] I am trying to understand where the landscape is trying to be deployed. [15:01] 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0c:29:f0:b9:f4 brd ff:ff:ff:ff:ff:ff inet 192.168.154.128/24 brd 192.168.154.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::20c:29ff:fef0:b9f4/64 scope link valid_lft forever preferred_lft forever 3: eth1: mtu 1500 qdisc pfifo_fast stat [15:01] 3: eth1: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0c:29:f0:b9:fe brd ff:ff:ff:ff:ff:ff inet 1.1.1.10/24 brd 1.1.1.255 scope global eth1 valid_lft forever preferred_lft forever inet6 fe80::20c:29ff:fef0:b9fe/64 scope link valid_lft forever preferred_lft forever [15:02] this is the maas server that I'm running the openstack-install er on.. [15:02] eth1 is the maas management network. [15:03] this is the node that juju-bootstrap was deployed. [15:03] 3: eth1: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0c:29:99:11:38 brd ff:ff:ff:ff:ff:ff inet6 fe80::20c:29ff:fe99:1138/64 scope link valid_lft forever preferred_lft forever [15:03] 4: juju-br0: mtu 1500 qdisc noqueue state UP group default link/ether 00:0c:29:99:11:2e brd ff:ff:ff:ff:ff:ff inet 1.1.1.3/24 brd 1.1.1.255 scope global juju-br0 valid_lft forever preferred_lft forever inet6 fe80::20c:29ff:fe99:112e/64 scope link valid_lft forever preferred_lft forever [15:04] Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 1.1.1.1 0.0.0.0 UG 0 0 0 juju-br0 1.1.1.0 * 255.255.255.0 U 0 0 0 juju-br0 [15:04] 1.1.1.1 is a simple router that is nat'ing a WAN address.. [15:06] brendand, what all info do you need to help? === med_ is now known as Guest82506 === Guest82506 is now known as medberry === medberry is now known as med_ [16:37] Bug #1578713 opened: maas cli help message shows API 1.0 after upgrade to 2.0 [16:55] Bug #1578729 opened: [2.0] MAAS DNS manageent should support SSHFP RRtype [18:57] issue: i have MAAS (1.9.1+bzr4543-0ubuntu2 (trusty1)) with two managed subnets (DHCP + DNS). when I PXE boot a server behind one of these interfaces it is getting an IP address from the correct subnet, but the "DHCP IP" reported by the PXE client is the IP of the other subnet and thus the TFTP fails. the DHCP config /var/lib/maas/dhcpd.conf seems to have the correct values in terms of next-server and dhcp-server-identifier. can't fi [19:35] Bug #1578791 opened: MAAS DNS management should allow the user to turn on DNSSEC for the domain. [19:45] mpontillo: ^ [19:46] thanks bdx ;-) [19:47] dbainbri: that is a known error, put some heat + your remarks on this bug -> https://bugs.launchpad.net/maas/+bug/1521618 [19:47] bdx: dbainbri: oh yeah, I forgot about this one... the ISC DHCP bug. sigh. [19:48] dbainbri: it wasn't totally clear from your description that it was, in fact, that bug - can you provide any other info? what are you trying to do with the node? (enlist? commission? deploy?) [19:48] dbainbri: it may be helpful to grab a packet capture during the time the node boots, to confirm the issue [19:54] dbainbri: if you feel like grabbing a packet capture, I find it's easiest to SSH to the machine running maas-rackd and run something like: tcpdump -s 0 'port not 22' -n -w triage.pcap [19:56] bdx: it was during all phases. [19:57] bdx: the PXE client indicated that it received a DHCP IP from the other subnet (didn't do a packet capture) [19:57] bdx: i will look at the bug and some heat [20:01] dbainbri: I've hit your exact issue before actually .... It prevented me from using maas for dhcp on subsequent subnets other than my maas-mgmt-net in maas1.9 .... I think this has been resolved in 2.0 though [20:01] dbainbri: pmontillo should know more [20:02] dbainbri: my suggestion at this point is to get a packet capture to confirm the issue; if you can get a separate packet capture from each network, that could be helpful [20:03] dbainbri: if you want to try MAAS 2.0 (currently in beta) as bdx suggests, you'll need to move to 16.04 (Xenial), so you'd get whatever fixes/improvements in that version of ISC DHCP, which might avoid the issue (if it is indeed the ISC DHCP bug that was mentioned) [20:04] mpontillo: i will try to get a packet capture when i get a chance. do you mean you can't use MAAS 2.0 w/o moving to 16.04? I have a constraint of staying on 14.04LTS [20:11] Bug #1578800 opened: RackControllerService flooding log with exceptions [20:13] dbainbri: correct; MAAS 2.x+ requires 16.04. [20:14] Bug #1578800 changed: RackControllerService flooding log with exceptions [20:15] mpontillo: thx, which means, even if the bug is fixed in 2.0, it won't help me. [20:23] Bug #1578800 opened: RackControllerService flooding log with exceptions [22:23] I'm trying to deploy a xenial unit on maas with juju, I checked xenial to import last week, and on the maas UI it looks like it's available. But when I try to do it, I get this: [22:23] https://www.irccloud.com/pastebin/DDUhkBwX/ [22:24] any way to confirm what's missing with xenial? on the web ui it seems to think it's there