Add a Kea DHCP backend
Spec to add a Kea DHCP server as a new backend for Ironic and Neutron. Related-Bug: #2081847 Change-Id: I3324cd4864a87c16a404238bf54dc2aa16a2e64a
This commit is contained in:
cid
parent
6962db3aad
commit
9dd4fdfcbc
245
specs/approved/kea-dhcp-backend.rst
Normal file
245
specs/approved/kea-dhcp-backend.rst
Normal file
@ -0,0 +1,245 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
================
|
||||
Kea DHCP backend
|
||||
================
|
||||
|
||||
https://bugs.launchpad.net/ironic/+bug/2081847
|
||||
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
DHCP is a critical service for assigning IP addresses to instances in
|
||||
OpenStack deployments. Both Ironic and Neutron rely on dnsmasq to provide
|
||||
DHCP services. However, dnsmasq has become increasingly unreliable,
|
||||
with intermittent DHCP failures, frequent restarts and crashes of dnsmasq
|
||||
processes, etc.
|
||||
|
||||
Refer to the bug on dnsmasq here:
|
||||
https://bugs.launchpad.net/ironic/+bug/2026757.
|
||||
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
Add a new Kea DHCP backend for Ironic and Neutron as an alternative DHCP
|
||||
provider. This will provide a more reliable DHCP option that's easily
|
||||
extensible while maintaining compatibility with existing systems.
|
||||
|
||||
* Create a new DHCP provider class extending the BaseDHCP interface.
|
||||
* Add configuration options to enable and configure Kea DHCP.
|
||||
* Add methods to manage DHCP options, leases, and port updates using Kea APIs.
|
||||
* Ensure DevStack support for Kea
|
||||
* Update documentation to cover the addition of Kea DHCP, setup and usage.
|
||||
|
||||
Ironic will interact with the Kea DHCP server via HTTP-based APIs [1]_.
|
||||
|
||||
* ``config-get``, ``config-set``: Manage Kea configuration
|
||||
* ``reservation-get``: Retrieve host reservations that will be handled
|
||||
externally via a host-reservation database shared between Kea and
|
||||
Ironic/Neutron query to retrieve reservation data. Dynamic reservation
|
||||
updates (``reservation-add`` and ``reservation-del``) require a premium ISC
|
||||
subscription and are not supported in this implementation [3]_.
|
||||
* ``lease4-get``, ``lease6-get``: Retrieve lease information
|
||||
* ``subnet4-add``, ``subnet6-add``: Add new subnets
|
||||
* ``statistic-get``: Monitor DHCP server statistics
|
||||
|
||||
The Kea DHCP backend can be added with or without an agent layer. Both
|
||||
approaches will use Kea's HTTP-based APIs, but differ in their architecture
|
||||
and how Ironic interacts with the Kea DHCP server.
|
||||
|
||||
An agent approach has more moving parts and complexity, but better scalability
|
||||
for large deployments, local management of Kea instances and reduced network
|
||||
traffic to central Ironic service.
|
||||
|
||||
* Flow: Ironic → Driver → Agents → Kea Servers
|
||||
* Kea DHCP Agent is deployed on each DHCP server node and manages local Kea
|
||||
config and handles communication between Ironic and Kea.
|
||||
* Ironic DHCP Driver implements Ironic DHCP interface and communicates with
|
||||
the Kea DHCP Agent.
|
||||
* Ironic sends DHCP configuration to Ironic DHCP Driver which in turn
|
||||
distributes it to Kea agents to apply config to local Kea servers.
|
||||
* For lease management, agents monitor local Kea lease changes report changes
|
||||
back to Ironic DHCP Driver.
|
||||
|
||||
The agentless approach will have a much simpler architecture, probably easier
|
||||
to implement and maintain with direct control from Ironic, but may not scale
|
||||
as well, increased network traffic to Kea servers and even a potential
|
||||
performance impact on Ironic for large-scale operations.
|
||||
|
||||
* Flow: Ironic driver translates configs to Kea API calls and applies changes
|
||||
directly to Kea servers.
|
||||
* Ironic manages all Kea servers, through direct Kea API no agent layer.
|
||||
* The Ironic driver translates configs to Kea API calls and applies changes
|
||||
directly to Kea servers.
|
||||
* For lease management, maybe a periodic polling of Kea servers for lease
|
||||
updates, or, a webhook mechanism.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
* Find a way to improve existing Dnsmasq implementations. It's worth noting
|
||||
that dnsmasq has inherent limitations as it's really intended for small
|
||||
computer networks even though Ironic has been using it for the longest, so
|
||||
addressing these problems may require significant re-engineering. It's also
|
||||
single maintainer OSS project, as of the time of this specification.
|
||||
The fact it is a single maintainer project results in long spans of
|
||||
inactivity, which increases consumer risk for a project like OpenStack.
|
||||
* Use a different DHCP provider than Kea that is also actively maintained,
|
||||
provides the reliability, flexibility, and integration Kea offers or better.
|
||||
* Develop a completely new, custom DHCP server which will be quite an
|
||||
undertaking and additional long-term technical debt.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
No changes to Ironic's data model are required.
|
||||
|
||||
State Machine Impact
|
||||
--------------------
|
||||
|
||||
No changes to the state machine are required.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
No changes to the REST API are required.
|
||||
|
||||
|
||||
Client (CLI) impact
|
||||
-------------------
|
||||
|
||||
No changes to python-ironicclient are required.
|
||||
|
||||
RPC API impact
|
||||
--------------
|
||||
|
||||
No changes to the RPC API are required.
|
||||
|
||||
Driver API impact
|
||||
-----------------
|
||||
|
||||
A new DHCP provider class will be added, but this should not impact existing
|
||||
drivers.
|
||||
|
||||
Nova driver impact
|
||||
------------------
|
||||
|
||||
None
|
||||
|
||||
Ramdisk impact
|
||||
--------------
|
||||
|
||||
No changes to the ironic-python-agent or ramdisk are required.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
There's no expected security trade-offs with the addition of a Kea DHCP
|
||||
backend. The increase in options for operators limits overall risk by
|
||||
providing additional options, which should be a net security gain.
|
||||
|
||||
In the event of such occurrences in the future, its active development will
|
||||
likely ensure timely security updates.
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Scalability impact
|
||||
------------------
|
||||
|
||||
Kea DHCP is designed for better scalability than dnsmasq, which could improve
|
||||
performance, especially for large deployments.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
Kea DHCP will likely offer performance improvements over dnsmasq, especially
|
||||
for large deployments with thousands of machines.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
Deployers will need to install and configure the Kea DHCP server
|
||||
alongside Ironic, likely in the same manner as dnsmasq, but with Kea-specific
|
||||
configurables such as network interfaces, IP address ranges, and lease times.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
Afonne-CID (cid).
|
||||
|
||||
Other contributors:
|
||||
Jay Faulkner (JayF).
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Write a Kea DHCP backend extending the BaseDHCP interface.
|
||||
* Add unit tests and DevStack support for running with Kea.
|
||||
* Configure at least one CI job to use Kea DHCP.
|
||||
* Add Bifrost support for the new Kea DHCP backend.
|
||||
* Implement unmanaged inspection support for Kea DHCP.
|
||||
* Update documentation.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
* Kea DHCP server [2]_.
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Add tests to verify full DevStack support, new Tempest tests specific to
|
||||
Kea DHCP functionality, and new unit tests for:
|
||||
* Retrieving lease information via Kea APIs.
|
||||
* Ensuring Kea correctly reads from the host-reservation database.
|
||||
|
||||
Upgrades and Backwards Compatibility
|
||||
====================================
|
||||
|
||||
Existing dnsmasq support will remain unchanged.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
* Full documentation on Kea’s capabilities and how it's different from dnsmasq
|
||||
with cross-references to external Kea resources.
|
||||
* Document configuration options and steps on switching from dnsmasq to Kea,
|
||||
including configuring Kea to use a read-only host-reservation database and
|
||||
how to set up Ironic/Neutron to manage this database.
|
||||
* Installation, configuration, and architecture documentations should present
|
||||
Kea as a configurable option, with clear instructions on how users can choose
|
||||
between Kea and dnsmasq.
|
||||
* API documentation will need to be updated to reflect any changes to existing
|
||||
methods and how they now interact with Kea compared to dnsmasq.
|
||||
* Sections of the current documentation that might have referenced dnsmasq as
|
||||
the default or only DHCP provider will need to be updated to reflect that
|
||||
Kea is now also a supported backend.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [1] https://kea.readthedocs.io/en/latest/api.html
|
||||
.. [2] https://www.isc.org/kea/
|
||||
.. [3] https://kea.readthedocs.io/en/latest/arm/hooks.html
|
||||
1
specs/not-implemented/kea-dhcp-backend.rst
Symbolic link
1
specs/not-implemented/kea-dhcp-backend.rst
Symbolic link
@ -0,0 +1 @@
|
||||
../approved/kea-dhcp-backend.rst
|
||||
Loading…
Reference in New Issue
Block a user