Skip to content

Add KEA DHCP provider feature for foreman-proxy#531

Draft
archanaserver wants to merge 3 commits into
theforeman:masterfrom
archanaserver:dhcp-kea-external
Draft

Add KEA DHCP provider feature for foreman-proxy#531
archanaserver wants to merge 3 commits into
theforeman:masterfrom
archanaserver:dhcp-kea-external

Conversation

@archanaserver

@archanaserver archanaserver commented Jun 1, 2026

Copy link
Copy Markdown
Contributor

Why are you introducing these changes? (Problem description, related links)

ISC DHCP reached end-of-life in October 2022 and has been removed from RHEL 10. This adds support for KEA DHCP as the replacement.

What are the changes introduced in this pull request?

  • Add dhcp-kea-external feature definition to src/features.yaml
  • Create Smart Proxy configuration template dhcp_kea_api.yml.j2
  • Add default Ansible variables for KEA server connection (localhost:8000, default subnet)
  • Add integration tests for DHCP KEA feature validation

How to test this pull request

Steps to reproduce:

  1. Verify feature is available: ./foremanctl features | grep dhcp-kea-external
  2. Deploy with KEA DHCP feature enabled: ./foremanctl deploy --add-feature dhcp-kea-external
  3. Verify feature is enabled: ./foremanctl features --list-enabled | grep dhcp-kea-external
  4. Check configuration file was created: podman exec foreman-proxy ls -la /etc/foreman-proxy/settings.d/dhcp_kea_api.yml
  5. Run tests python -m pytest tests/foreman_proxy_test.py::test_dhcp_kea_feature_present -v

Checklist

  • Tests added/updated (if applicable)
  • Documentation updated (if applicable)

Adds the dhcp-kea-external feature to enable Smart Proxy integration
with external KEA DHCP servers.
Comment thread src/features.yaml Outdated
description: Power management for bare metal hosts (IPMI, Redfish)
foreman_proxy:
plugin_name: bmc
dhcp-kea-external:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the feature should be "dhcp" and then you add a parameter to select which provider to use, with kea being one of the answers

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes way more sense to have a single dhcp feature with a provider parameter

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I played with that thought in #532 for the DNS side of things, would love to hear your opinion on the approach I took

foreman_proxy_bmc_redfish_verify_ssl: true

# KEA DHCP settings (external unmanaged server)
foreman_proxy_dhcp_kea_server: localhost

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are the chances that localhost is a place where a Kea will actually run (outside of development setups)?

I think we should leave that undef (like in https://github.com/theforeman/foremanctl/pull/523/changes) and force the user to set a sensible value.


:enabled: {{ feature_enabled }}
:use_provider: dhcp_kea_api
:server: {{ foreman_proxy_dhcp_kea_server }}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where does this come from? I don't see such an option in https://gitlab.surrey.ac.uk/sm0049/smart-proxy-dhcp-kea-api/

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, i was just playing around with few things, needed to look again, the reason i added that in draft but thanks for reviews, also i tryna fix few things with the updated changes.

:enabled: {{ feature_enabled }}
:use_provider: dhcp_kea_api
:server: {{ foreman_proxy_dhcp_kea_server }}
:kea_url: {{ foreman_proxy_dhcp_kea_url }}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this be kea_api_url?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, we need kea_api_username and kea_api_password

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes def

:use_provider: dhcp_kea_api
:server: {{ foreman_proxy_dhcp_kea_server }}
:kea_url: {{ foreman_proxy_dhcp_kea_url }}
:kea_subnet: {{ foreman_proxy_dhcp_kea_subnet }}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where does this come from? I don't see such an option in https://gitlab.surrey.ac.uk/sm0049/smart-proxy-dhcp-kea-api/

@evgeni

evgeni commented Jun 1, 2026

Copy link
Copy Markdown
Member

Shall we package https://gitlab.surrey.ac.uk/sm0049/smart-proxy-dhcp-kea-api until we figure out whether we want to merge it into core or not?

@archanaserver

archanaserver commented Jun 2, 2026

Copy link
Copy Markdown
Contributor Author

Shall we package https://gitlab.surrey.ac.uk/sm0049/smart-proxy-dhcp-kea-api until we figure out whether we want to merge it into core or not?

Yeah, I was thinking we can package it for now, that will be independent of our decision about potentially merging it into the core later.

foreman_proxy_bmc_redfish_verify_ssl: true

# DHCP settings
foreman_proxy_dhcp_provider: dhcp_kea_api

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just:

Suggested change
foreman_proxy_dhcp_provider: dhcp_kea_api
foreman_proxy_dhcp_provider: dhcp_kea

:kea_api_password: {{ foreman_proxy_dhcp_kea_api_password }}
{% endif %}
{% if foreman_proxy_dhcp_kea_managed_subnets is defined and foreman_proxy_dhcp_kea_managed_subnets %}
:managed_subnets:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

foreman_proxy_dhcp_kea_api_url: "{{ undef(hint='You must specify the KEA API URL') }}"
foreman_proxy_dhcp_kea_api_username: ""
foreman_proxy_dhcp_kea_api_password: ""
foreman_proxy_dhcp_kea_managed_subnets: []

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be:

Suggested change
foreman_proxy_dhcp_kea_managed_subnets: []
foreman_proxy_dhcp_subnets: []

as in https://github.com/theforeman/smart-proxy/blob/develop/config/settings.d/dhcp.yml.example

@evgeni

evgeni commented Jun 2, 2026

Copy link
Copy Markdown
Member

Shall we package https://gitlab.surrey.ac.uk/sm0049/smart-proxy-dhcp-kea-api until we figure out whether we want to merge it into core or not?

Yeah, I was thinking we can package it for now, that will be independent of our decision about potentially merging it into the core later.

Do you want to do it, or shall I?

Comment thread src/features.yaml
@archanaserver

Copy link
Copy Markdown
Contributor Author

Shall we package https://gitlab.surrey.ac.uk/sm0049/smart-proxy-dhcp-kea-api until we figure out whether we want to merge it into core or not?

Yeah, I was thinking we can package it for now, that will be independent of our decision about potentially merging it into the core later.

Do you want to do it, or shall I?

I'll do it

@archanaserver archanaserver marked this pull request as ready for review June 4, 2026 09:51
@archanaserver

Copy link
Copy Markdown
Contributor Author

Update: Following the refinement session, we decided to integrate the KEA DHCP provider directly into smart-proxy core rather than packaging it as an external gem. I'm on it. So keeping this into draft till then.

Also looking at the current CI test failures, I believe they are coming from IOP tests failures and are unrelated to the DHCP feature changes in this PR.

@archanaserver archanaserver marked this pull request as draft June 11, 2026 09:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants