[11:09] <Razva> haasn you around?
[11:12] <Razva> it seems that my LAN servers cannot detect MAAS DHCP
[11:12] <Razva> any ideas of how to debug this?
[11:13] <Razva> ps aux | grep dhcp
[11:13] <Razva> dhcpd     6631  0.0  0.0  32916 13324 ?        Ss   13:04   0:00 dhcpd -user dhcpd -group dhcpd -f -q -4 -pf /run/maas/dhcp/dhcpd.pid -cf /var/lib/maas/dhcpd.conf -lf /var/lib/maas/dhcp/dhcpd.leases eno2
[11:13] <Razva> root      6740  0.0  0.0   9496  2192 pts/1    S+   13:06   0:00 grep --color=auto dhcp
[11:13] <Razva> eno2 being the LAN nic
[13:29] <roaksoax> Razva: i'd connect a machine to that network and try to DHCP
[13:38] <Razva> roaksoax that's exactly what I'm doing
[13:38] <Razva> but seems that the "client" doesn't "asks" for DHCP
[13:39] <Razva> I've reinstalled Ubuntu 14 + MAAS, the result is the same
[13:40] <Razva> 0:00 /usr/sbin/dhcpd -user dhcpd -group dhcpd -f -q -4 -pf /run/maas/dhcp/dhcpd.pid -cf /var/lib/maas/dhcpd.conf -lf /var/lib/maas/dhcp/dhcpd.leases em2
[13:40] <Razva> em1       Link encap:Ethernet  HWaddr d4:ae:52:c7:0f:4d
[13:40] <Razva>           inet addr:217.19.1.2  Bcast:217.19.1.255  Mask:255.255.255.0
[13:40] <Razva> em2       Link encap:Ethernet  HWaddr d4:ae:52:c7:0f:4e
[13:40] <Razva>           inet addr:10.0.2.10  Bcast:10.0.2.255  Mask:255.255.255.0
[13:41] <Razva> auto em2
[13:41] <Razva> iface em2 inet static
[13:41] <Razva> address 10.0.2.10
[13:41] <Razva> netmask 255.255.255.0
[13:42] <Razva> maas-dhcpd start/running, process 1123
[13:42] <Razva> isc-dhcp-server stop/waiting
[13:42] <roaksoax> Razva: my guess is that this has to do something with your network / switch configuration
[13:57] <Razva> I've contacted the DC, they are "investigating". God I'm so tired about this issue.
[13:57] <Razva> offtopic: do you recommend using Flat layout or LVM, for Ubuntu Cloud setups?
[13:59] <roaksoax> Razva: depends on what you want/need. Right now we are defaulting to Flat layout for backwards compatibility. For the future, we may default for LVM
[14:04] <Razva> ok, so should I use LVM for a new cluster?
[14:06] <roaksoax> Razva: that's totally up to you :)
[14:10] <haasn> Razva: if you manually set up networking information, can the machines reach each other?
[14:10] <haasn> Razva: also check tcpdump on all machines
[15:07] <kiko> Razva, typically you'd use flat for "cattle-style" app deployment
[15:31] <mup> Bug #1546143 opened: Web UI crashes when rack controller not available <MAAS:Triaged> <MAAS trunk:Triaged> <https://launchpad.net/bugs/1546143>
[17:01] <Razva> roaksoax just fyi, it WAS a networking issue
[17:01] <Razva> so I've lost ~3 days because of a darn DC admin who was unable to understand the simple fact that I want to DHCP boot from my VLAN :)
[17:03] <kiko> Razva, perhaps you'd be surprised to know that in any deployment canonical does, getting the setup to the point where maas can be installed and works is often a week!
[17:04] <kiko> Razva, on the roadmap we have some network health checking built in that will improve this piece of the game
[17:23] <mup> Bug #1546208 opened: Spurious test failure in TestMachinePartitionListener.test__calls_handler_with_update_on_update <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1546208>
[17:31] <Razva> kiko wow. well the issues were simple...
[17:32] <Razva> like...IPMI wasn't started on iDRAC, the VLAN didn't allowed DHCP, we had another DHCP server running without our agreement etc. but all were "solvable" by me (I'm a newb)
[17:45] <kiko> Razva, simple but waste a lot of time, I bet?
[18:20] <mup> Bug #1546235 opened: Spurious test failure in TestPrivateCacheBootSources.test__doesnt_have_env_http_and_https_proxy_set_if_disabled <tests> <MAAS:Triaged> <MAAS trunk:Triaged> <https://launchpad.net/bugs/1546235>
[18:30] <Razva> kiko yup, 3 days.
[18:31] <kiko> Razva, that's what I meant
[18:31] <Razva> yeah but still, they ask for a private switch, specific hardware and so on. so their request is...ideal.
[18:32] <Razva> most issues I had with networking and me not knowing some basic things, like the fact that you have to set the VLAN nic to boot from the VLAN :D
[18:36] <Razva> any idea why maas doesn't shows any disks for machines in "Ready" state?
[18:36] <Razva> ipmipower -D LAN_2_0 -h 109.169.19.75 -u root -p G5djW*pbv --stat
[18:36] <Razva> sorry
[18:36] <Razva> damn now I need to reset IPMI password :))))))))
[18:37] <Razva> Storage 0.0GB over 0 disks
[18:39] <kiko> Razva, if you just reenlist the node MAAS sets up IPMI automatically in the enlistment process
[18:39] <kiko> Razva, there's no need to mess with the creds directly
[18:39] <kiko> Razva, the storage thing is interesting, did you successfully commission? if so, can you take a look at your hardware output on the node view and see if storage was detected correctly?
[19:14] <Razva> kiko solved my re-comissioning everything. weird.
[19:14] <Razva> they all successfully comissioned previously.
[19:20] <Razva> any idea if Dell servers require IPMI to be enabled from DRAC?
[19:24] <kiko> Razva, I'm pretty sure they do
[19:24] <dbainbri> Is MAAS filtering out lease updates to DNS (bind9) if the MAC address is not a known node? Is there a setting to make this not happen so all leases are updated to DNS?
[19:25] <kiko> all leases are sent to DNS dbainbri
[19:25] <kiko> the dynamic range is sent in a bulk zone
[19:26] <kiko> and provisioned nodes and devices are added individually
[19:26] <kiko> this is all assuming 1.9
[19:26] <kiko> dbainbri, having said that, I think we did receive a bug report where some leases were missing
[19:26] <kiko> dbainbri, or a verbal/IRC report if not an actual bug
[19:33] <dbainbri> ok, it looks like only those leases handed out to PXE boot devices (and in the node list) are being updated in the zone file
[19:34] <dbainbri> i am using 1.9
[19:34] <dbainbri> i have some other devices that are getting addresses from DHCP, but are not making it to the zone file.
[19:38] <kiko> dbainbri, do the generated DNS zone files have GENERATE statements that should cover the IPs that were handed out?
[19:39] <dbainbri> yes
[19:39] <kiko> dbainbri, if not, could you file a bug including them and the details for the nodes and actual queries (dig, etc) that are returning NXFOUND?
[19:39] <kiko> hmm
[19:39] <kiko> okay, either way it's a bug then
[19:39] <dbainbri> ok, i will take one last look around and if nothing sticks out, i will file a bug, thx.
[19:39] <kiko> I need to split but if you file it and /msg me I'll look into it tomorrow as this confirms a suspicion I have
[19:39] <kiko> thanks very much
[19:39] <kiko> roaksoax, ^^
[19:46] <roaksoax> kiko: bah, he left, but all devices that get IP's from dynamic range get a DNS based on IP
[21:00] <mup> Bug #1546301 opened: "auto assign" on unmanaged subnet used the gateway IP for the node <kanban-cross-team> <landscape> <MAAS:Fix Committed> <MAAS 1.10:Triaged> <MAAS 1.9:Triaged> <https://launchpad.net/bugs/1546301>
[21:06] <mup> Bug #1546301 changed: "auto assign" on unmanaged subnet used the gateway IP for the node <kanban-cross-team> <landscape> <MAAS:Fix Committed> <MAAS 1.10:Triaged> <MAAS 1.9:Triaged> <https://launchpad.net/bugs/1546301>
[21:12] <mup> Bug #1546301 opened: "auto assign" on unmanaged subnet used the gateway IP for the node <kanban-cross-team> <landscape> <MAAS:Fix Committed> <MAAS 1.10:Triaged> <MAAS 1.9:Triaged> <https://launchpad.net/bugs/1546301>
[21:24] <stormmore> amazing what you can learn about a dev team just by watching the bug changes. I love that “feature” guys :)
[22:28] <mup> Bug #1544779 opened: m400 cartridge (mcdivitt) unable to deploy Xenial <curtin:New> <MAAS:New> <maas-images:New> <https://launchpad.net/bugs/1544779>
[22:38] <Razva> any idea if Ubuntu Cloud will support the upgrade from 14 LTS to 16 LTS?
[22:38] <Razva> because at this point we're deploying 14 LTS (15 had a ton of issues)
[23:45] <dbainbri> kiko: submitted as https://bugs.launchpad.net/maas/+bug/1546344
[23:49] <roaksoax> dbainbri: DNS mappings are only given based on node names for the IP the PXE interface gets in 1.9
[23:49] <roaksoax> dbainbri: for anything else that get;s an IP from the Dynamic range, the DNS is based on the IP itself
[23:51] <roaksoax> dbainbri: ah, you are using 1.8 even. Yeah so DNS for stuff in dynamic range is based on ip: 192-168-1-1.maas or similar
[23:52] <mup> Bug #1546344 opened: DNS not being updated with hosts not managed by MAAS <MAAS:New> <https://launchpad.net/bugs/1546344>
[23:52] <dbainbri> @roaksoax: so MAAS isn't meant to propagate names to bind or things it gives IP addresses, except if they are PXE boot nodes?
[23:53] <dbainbri> @roaksoax: i.e. doesn't use the client ID
[23:55] <roaksoax> dbainbri: right, so MAAS would provide DNS based on the node name for the machines we deploy, but only for the IP of the PXE interface
[23:55] <dbainbri> @roaksoax: fwiw, i son't see names based on the IP in the DNS files either (for those hosts that are not MAAS nodes)
[23:56] <roaksoax> dbainbri: this is generated dynamically
[23:56] <roaksoax> dbainbri: ping 192-168-1-2.maas -> try to ping like that ?
[23:56] <dbainbri> roaksoax: ok, unfortunate. would like to see it generate names for everything, at least as a config options
[23:57] <roaksoax> dbainbri: that's not a 1.8/1.9 thing. There will be PTR records for everything that MAAS assigns statically on 2.0 though
[23:58] <dbainbri> the IP based name (192-168-x-x.maas) isn't in the zone files and ping does not work
[23:59] <dbainbri> ok, had to use the right domain (which i have customized) and that worked, but doesn't really help me ;)
[23:59] <roaksoax> dbainbri: $GENERATE 28-150 $.10.168.192.in-addr.arpa. IN PTR 192-168-10-$.maas.
[23:59] <roaksoax> that's mi zone file, for example