[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).