Foreman DHCP management capabilities is a clunky feature, it is what
it is, it dates back to the initial days when provisioning was added
by the community. The DHCP Smart-Proxy has a very simple API: get me all
IPs, get me IP by MAC, get me MAC by IP, add a new record (MAC+IP).
Foreman uses this to manage DHCP records on the ISC DHCP server that
ships with RHEL.
See, I don’t think Foreman should be part of the IPAM business, it’s
a complicated thing and the market is pretty much all filled up.
Foreman only offers poor’s-man “give me next IP address in sequence”
of “give me random IP address from this pool”. But IPAM is much more
than that, you have organizations, groups, subnets, pools, segments
and projects, you want to know who owns which IP address and typically
you want IP addresses to be associated with DNS records or integrated
with identity management.
The community only recently added External IPAM feature, the Smart-Proxy
API is still incubating. It has been a long process due to lack of time of the
main author. In the meantime, we have added webhooks which could be a good
alternative to do DHCP/DNS integration, not perfect but doable with advantage
that users can write scripts/services for any kind of providers easily.
One might think that DHCP management is a feature that is needed for
provisioning, but that is not the case. In order to do PXE/HTTP BOOT
provisioning, Foreman only need to manage TFTP/HTTP bootloader
config files (PXELinux, Grub2) and as long as the networking team
ensures that a DHCP server replies with PXE options (which TFTP/HTTP
to use essentially). To find associated host information, we have
provisioning tokens which are placed into TFTP PXE configuration
files, and even if this is turned off Anaconda installer is able to
figure out the details as it sends MAC address in the kickstart
request in HTTP headers and Foreman can leverage this to find the host
details in its inventory when tokens expire or are turned off.
Granted, some operating systems offer neither MAC address sending nor
provisioning tokens, therefore not managing DHCP would mean that
customers would be unable to do provisioning of niché operating
systems. In these scenarios, Foreman has a fallback mechanism of
detecting the host which is booting via its (REMOTE) IP address. This
information is matched against the inventory of provisioning NICs to
match the host. But Red Hat based or Debian based all do work fine,
most linuxes as well.
When creating a new managed host, users are required to associate a
Subnet (and Domain), this is essential for other features (e.g. which
Smart-Proxys to use), however, it automatically assumes that you want to
do provisioning and enforces to fill in an IP address - either via
DHCP “IPAM” feature (pick the next free IP from DHCP Smart-Proxy or use
internal DB table) or manually. I saw several BZs reported by
customers through the years asking to relax this requirement as they
never intended to use Foreman for provisioning and this is exactly
what I am proposing. We should allow hosts with blank IP addresses.
Infoblox dependencies dying is not the only reason why I propose this
change, there is one far more important. In the IPv6 world, you cannot
do IP address pre-reservation for unknown hosts (yet to be
provisioned), DHCPv6 protocol is vastly different from its older
brother and they deliberately omitted MAC addresses from it (it has
DUID now instead). Even if we want to keep DHCPv4 management in
Foreman, customers who already use DHCPv6 cannot use it with
Foreman and need to use the approach I am proposing here - unmanaged
DHCPv6 server that “points” to the Foreman TFTP Smart-Proxy.
And there is more, not only is the DHCPv6 protocol not capable of
associating host records without DUIDs, RHEL does not ship the
next-generation DHCPv6 server ISC Kea for various (license, technical)
reasons. The one that is included in RHEL8/9 is ISC DHCP which does
not offer any DHCPv6 management capabilities. So even if we added some
DUID support into Foreman, we cannot technically create those
records on the ISC DHCP server today.
And there is the old and famous “single subnet installer problem”. Our
Puppet installer only sets up a single subnet, if you want multiple
you need to use the (now documented) Hiera YAML approach. It’s because
our limited DHCP API does not offer any kind of subnet management
capabilities, you need to configure subnets externally and only then
Foreman can manage records within those subnets. This is not a bad
practice as it allows more simple API and less code to worry about,
however, it’s confusing and our workaround is the foreman_setup plugin
which often breaks upstream (it is not shipped with Foreman AFAIK).
This change would not come free of course, we have many places (e.g.
in templates) when we test @host.subnet.present? and if so, we assume
an IP address is also present. We would need to change this to
@host.ip.present? or @host.ip6.present? (@host.any_ip?) but that is an
easy change.
If this is successful we could even take this further and remove DNS
management capabilities and replace this with webhooks so customers
would have a fully tested webhook-based approach so they could use
pretty much any DNS provider they want. Today, DHCP and DNS
orchestration is separate, but this does not make sense (actually is a
known problem for Infoblox integration today) for some IPAM systems
where hosts are single entries for both DHCP and DNS (e.g. again
Infoblox), therefore they would simplement just a single webhook
script/service to create both DHCP and DNS.
