DHCP snippets limitation/bug

UX
1

My environment is large, its a combination of bare metal and VM’s (openstack). Maas needs to be able to provision for vlan’s that span both bare metal space and openstack.
Openstack VM’s use DHCP by default and we don’t want MaaS to answer for those (should be easy, the OUI for openstack is the same so we should be able to drop in snippets to do what we want, but alas

For the life of me it looks like there’s a limitation in maas with DHCP snippets set for subnets, in that they get placed OUTSIDE of the pool{} block which means things like
deny members of “openstack”;
in a subnet snippet

I have two snippets: a global one:
match_if_openstack
Type: Global
DHCP snippet:
class “openstack” {
match if ((substring(hardware,0,3) = fa:16:3e) and (substring(option dhcp-client-identifier, 0, 4) != “MAAS”));
}
This should classify all openstack vm’s EXCLUDING the rack controllers which probe with option 61 being set with “MAAS” in it

So now to tell a subnet not to repond to DHCP requests from openstack classified devices
I try
a new snippet “deny_openstack_test”
Type: Subnet:
Applies to: a.b.c.d/22
DHCP snippet:
deny members of “openstack”;

Maas then places this within the subnet block but OUTSIDE OF THE POOL

       deny members of "openstack";
       pool {
          range 10.40.195.200 10.40.195.221;
       }

and dhcp promptly explodes with

/var/snap/maas/common/maas/dhcpd.conf line 505: expecting allow/deny key
deny members
^
/var/snap/maas/common/maas/dhcpd.conf line 505: expecting a parameter or declaration
deny members of “openstack”;
^
Configuration file errors encountered – exiting

isc dhcpd docs state that deny members of “classname” needs to be INSIDE THE POOL
http://www.ipamworldwide.com/ipam/dhcp-declare-allowdeny.html

1 Like
2

@dandruczyk, i’ve highlighted your recent troubles to the MAAS core team, as you’ve been struggling bravely through several issues lately. they’re in the middle of a release & planning cycle, so they may not be available quickly – but rest assured that we’ve noticed your pattern of issues and it does concern us. not an immediate answer, i know, but i’m trying to bring your issues to the top of the pile. bear with us.

3

Thank you. I’m sure I’ll find more as I have one of your larger maas installs…

I do notice that during the end of deployment there’s always a service that sits for 1min 30 seconds in the shutdown to the reboot phase. In typical systemd fashion the text is cut off so it’s unclear what service is hanging up. I’ll try to gather more info on it if I can catch it in the act.