A proposal for Kea configuration design

Tomek Mrugalski tomasz at isc.org
Wed Apr 30 14:02:19 UTC 2014

As you all know, the major feature planned for upcoming Kea 0.9 is the
removal of BIND10 framework. The following is a proposal for how Kea
configuration is to be organized.

Before I get to the proposal, here are things we should consider:
- Although we plan to run Kea as stand-alone, Carsten Strotman from
Bundy project proposed that Kea could work in 2 modes: stand-alone and
as part of Bundy framework. While we're focusing on stand-alone mode and
do not have time for doing any Bundy framework related work, there are
apparently people who are interested in that. We should make their work
easier, if that doesn't bring in more work for us.

- Time is of the essence here. While we may come up with awesome new
configuration that requires complete rewrite, we need to have
stand-alone capability sooner rather than later. It is ok to temporarily
loose some capability.

- Once you get the concept, the configuration backends are natural
extension of the lease database backend concept to the configuration
part. Even though we're going to support only one backend for the
foreseeable future, that's the same as we had abstract LeaseMgr API when
we did support only MySQL.

Many parts of that proposal were suggested by Thomas (thanks a lot!).

1. Add capability to have switchable backends.
A new parameter called --with-kea-config will be implemented in
configure script. It will allow selecting at compilation time how the
servers will be configured. For the next 2-3 months, we'll have 2
values: JSON (read from file) and BIND10 (use bind10 framework). Once we
have file based configuration implemented and we're ready to switch
(i.e. enough confidence, Forge tests updated for new configuration
mechanism), we get rid of BIND10 option. This switchable backend is
really simple. There are just different implementations of
ControlledXSrv class, so it's a matter with compiling/linking one file
or another. Hence it is easy for us to remove the old backend (and for
Bundy folks to keep it if they desire so). It is also easy for other
organizations to add and maintain their own backends (e.g. LDAP based).

Just to be clear: as soon as the JSON file reader is ready, we are going
to remove BIND10 backend from Kea repo.

For extended rationale why this is needed, see section
dhcpv6ConfigBackend in file src/bin/dhcp6/dhcp6.dox on branch trac3400.

2. Retain config and command callbacks.
We can completely reuse the concept, there's really nothing wrong with
it. The command and arguments are all JSON text. In the 0.9 timeframe,
we'll be using mostly configuration callbacks. Usage of command
callbacks will be limited.

3. The commands callback will be there, but we'll use it only partially.
We'll support only the following commands "shutdown" (plugged into TERM
signal) and add new command "reload" (plugged into HUP signal).
libreload will be unusable for now. The reconfig will be relatively
simple in 0.9 timeframe. There is no way to send any extra information
using signals, so we'll just remember config file name and reread it.

4. After 0.9, we will design some form of secure socket that we'll be
able to send commands over. Whatever the design we end up with, it will
allow to send configs and commands in JSON format and get responses.

Once that is done, we'll have the same capability as we did in BIND10
framework: to send additional parameters. One obvious use case will be
to send new config file name as parameter for "reload".

5. Add a command handler for reading config from file
This handler should ultimately call the existing config handler, it's
main responsibility is to load config from file and process it.

6. Add extended JSON processor
It's just a fancy name for JSON comments remover for now. It will read
the file from disk and remove comments (original JSON format does not
allow comments). Ultimately (past 0.9) this will have other
capabilities, like files inclusion, multi-line comments etc. For 0.9
we'll settle for simple single line hash comments.

7. Implement common base class for Kea4, Kea6, D2 server
Some operations will be common for all 3 components: logger
initialization, extended JSON processing, signal handling, and some time
later control socket. This calls for a small base class that Dhcpv4Srv,
Dhcpv6Srv and D2Controller can use. We will start that
base class as very small one. It is expected to grow over time as we do
more code unification.

8. Extend lib/cc to do JSON manipulation as needed for #7. For now (0.9
timeframe) this will be only hash comment removal.

9. Extend lib/logging to support stand-alone init of logging.

10. Config file format.
We will use the current format of b10-config.db. This is slight change
to what we did in Kea, because we were receiving a subset of that
configuration. Let me give specific example. That's how b10-config.db
looks like today:

  "Init": { ... }
  "Dhcp4": {
    "subnet4" { subnet definitions here },
    "option-data" { option data here },
    "interfaces": [ "eth0" ],
  "Dhcp6": {
    "subnet6" { subnet definitions here },
    "option-data" { option data here },
    "interfaces": [ "eth0" ],
  "Logging": {
    "Loggers": [{"name": *, "severity": "DEBUG" }]

Kea components used to receive only relevant parts of it (e.g. Kea4
received config that contained content of the Dhcp4 element). We'll be
receiving the whole config now. The modification in the code is really
minor: just iterate over top level elements and pick the appropriate
tree (or get element by name). Also, that approach makes the logging
initialization code very easy to share among Kea4, Kea6 and D2.

11. We keep .spec files
We'll keep and maintain them even though we won't do anything with them.
Those files were used by bindctl to do syntax checking. We will be
lacking that capability for a while. Implementing C++ code for .spec
validation of received config is out of scope for 0.9 (and probably for
1.0 as this is pretty big task).

Ok, that's it. Comments? Thoughts? Tomatoes?


More information about the kea-dev mailing list