bundy

* Modular * Extensible * Friendly *

[Bundy-hackers] Importing DHCP components from Kea to Bundy?

Tomek Mrugalski tomasz at isc.org
Wed Jul 9 14:32:49 CEST 2014


Hi,

We (Carsten, Shane and couple others) had a discussion during RIPE in
Warsaw about DHCP components in Bundy. The general consensus was that
DHCP is a low priority for Bundy project and there is noone willing to
carry its development in Bundy. On the other hand, having DHCP
components there would help proving usefulness of the whole framework.
Hence the best course of action envisaged would be to import Kea
components into Bundy.

I think Kea is ready for this step. The latest Kea code no longer has
BIND10/Bundy framework, no longer requires Python3 and reads JSON
configuration files from disk. In essence 95% of the BIND10 framework
was removed. The only thing left is the capability of the DHCPv4, DHCPv6
and DHCP-DDNS components to connect to msgq and receive configuration
commands. That capability is disabled by default.

Kea configure script now offers a --with-kea-config switch, which
governs how Kea is being configured. The default value is JSON, which
will build Kea in stand-alone mode, where configuration is read from
files. What's interesting for Bundy project is --with-kea-config=BUNDY
option. It will build Kea with the backend that attempts to join msgq as
it did in BIND10 days.

I think it would be nice if someone from Bundy project could try to get
rid of the stale DHCP code from Bundy repo and develop a script that
imports the code from the Kea repo (see
http://kea.isc.org/wiki/GitGuidelines). From Kea perspective, the
integration with Bundy framework is nice to have, but completely
optional feature. As usual, our deadlines are challenging, so sadly
we're unable to help much more with the integration. However, if you
need little tweaks, we can probably change a thing or two.

Hope that helps,
Tomek
Kea project

p.s.
There's one other thing in Kea that you may be interested in. We do now
have the capability to use either Botan or OpenSSL. Although enthusiasm
for OpenSSL somewhat diminished in recent months, it's still useful to
have an alternative. That's implemented as ticket #2406
(http://kea.isc.org/ticket/2406).