Integrate KEA DHCP Provider into Smart Proxy

Development RFCs
1

RFC: Integrate KEA DHCP Provider into Smart Proxy

Context and Problem Statement

Smart Proxy currently supports multiple DHCP providers, with dhcp_isc being the default provider for ISC DHCP. While functional, ISC DHCP reached end-of-life ISC DHCP Server has reached EOL - ISC and is no longer maintained. While it is still available in RHEL 9, it is no longer shipped with RHEL 10, making it unsuitable as the default DHCP solution for future deployments.

Kea DHCP is the recommended replacement and is included in Enterprise Linux 10, as well as Debian (13+ with backports) and Ubuntu (26.04+) releases.Today, users who want to integrate KEA with Smart Proxy must rely on the external (smart_proxy_dhcp_kea_api) plugin. This results in additional installation and configuration steps and lacks an officially supported integration.

This proposes integrating KEA support directly into Smart Proxy core as a first-class DHCP provider. It does not immediately remove the existing ISC DHCP provider. The dhcp_isc provider will be marked as deprecated, and both providers will coexist to allow gradual migration, users are not required to migrate immediately, KEA server configuration remains external (similar to ISC DHCP).

Proposal

Introduce a new Smart Proxy provider, dhcp_kea, based on the functionality currently provided by the external smart_proxy_dhcp_kea_api gem.

The provider communicates with a remote KEA server through the KEA Control Agent API and follows the standard Smart Proxy provider pattern. Configuration is managed through settings.d YAML files using the dhcp_kea_* parameter prefix.

The initial implementation supports IPv4 DHCP reservations, lease management, PXE boot options, HTTP Basic Authentication, and SSL/TLS verification.It requires KEA DHCP with Control Agent enabled (tested with 3.0.3), and the libdhcp_host_cmds.so and libdhcp_lease_cmds.so hooks.

The changes are fully additive and include Smart Proxy support together with corresponding configuration support in foremanctl. This integration does not include KEA server installation or configuration, users must deploy and manage their KEA instances.

Alternative Designs

An existing Ruby gem named smart_proxy_dhcp_kea (smart_proxy_dhcp_kea | RubyGems.org | your community gem host) was considered. However, it has not been maintained since 2020 and was not suitable for upstream integration. Although the new provider name overlaps with the existing gem, we chose dhcp_kea because it aligns with the existing Smart Proxy provider naming convention (dhcp_isc, dhcp_native_ms, dhcp_libvirt) and reflects that this is a core Smart Proxy provider.

Migration Paths

ISC DHCP users: Existing deployments remain unchanged. Users who wish to migrate can deploy KEA, enable the Control Agent, migrate their DHCP configuration, and switch Smart Proxy to the dhcp_kea provider. DHCP reservations require manual migration, as KEA does not automatically import ISC DHCP reservation data.

External plugin users: Users can migrate by uninstalling the external plugin, switching to the dhcp_kea provider, updating configuration parameters to the dhcp_kea_* naming convention, and restarting Smart Proxy.

Decision Outcome

Status: Awaiting reviews

PRs:

Impacts

This integration provides a new dhcp_kea provider to Smart Proxy and corresponding support in foremanctl while keeping the current compatibility with existing ISC DHCP deployments. It provides an officially supported migration path to KEA DHCP and aligns Smart Proxy with platform defaults, such as RHEL 10. All changes are additive and introduce no breaking changes.

Workflow and Architecture Changes

For new deployments, KEA becomes the recommended DHCP provider, particularly on platforms where ISC DHCP is no longer available. Existing deployments remain unaffected and can migrate when appropriate.

Smart Proxy gains a new dhcp_kea provider and configuration template, while foremanctl adds support for configuring the provider to utilize an existing KEA deployment. Documentation will be updated to include installation, configuration, migration, and troubleshooting guidance.

6 Likes
2

I want to see this happen, but I am not sure if it would make sense to keep it a separate gem. As we have the plugin architecture in Foreman and Smart Proxy I never understand why tightly coupling something like including it in the same repository makes sense. Some time in the future we will need to remove it from the existing code base when another replacement is there. Also being installed by default is not an reason for me, as we can solve this in many other ways (on packaging level or the installer).

So my suggestion for an alternative design would be transferring the gem to the GitHub organization as a separate repository and work there on it instead of merging it into the Smart Proxy itself. How do you think about this?

4

I agree that the plugin architecture is an important point here. My initial reason for proposing this in Smart Proxy core was that Kea is expected to become the recommended replacement for ISC DHCP.

Since this is intended to be an officially supported provider and a long-term migration path from dhcp_isc, so I see this less as adding a new optional integration and more as providing a replacement path for existing core DHCP functionality. Having it in core would give us better release/testing coverage, make packaging and foremanctl integration simpler, and keep it aligned with the existing DHCP provider pattern like dhcp_isc, dhcp_native_ms, and dhcp_libvirt.

That said, I agree that an official separate plugin under the Foreman GitHub org could also work. If we go that route, I think we should clarify packaging, installer/foremanctl integration, release testing, and long-term maintenance so that Kea still feels like an officially supported provider rather than an optional third-party plugin.

I’d be open to hearing more thoughts from others on this.

5

While I agree that plugin architecture is a nice thing, I think having “core” features in the “core” repo is better as it makes them easier to ship and update if the core changes.

We see that a lot with Foreman and its plugins, where a change needs to be coordinated across repos. Granted, this is less likely a problem for the proxy, but still.