A proposal for Kea configuration design

[Stephen Morris]

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

Most important here is to define and document the API that will be
used.  Then we can add other backends as required.

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

Agree.

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

Agree.  Although regarding libreload, I think removing the library
from the configuration, reloading the configuration, adding it back
and reloading the configuration again may work.

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

We may want to use a TSIG-based solution (like rndc), simply because
the code is available for it. (More accurately, the C++ code will be
when TSIG support is added to the DHCP/DDNS process.)

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

Whole-line comments (hash must be first non-whitespace character in
the line) or do we allow inline commands (in which case we need to handle
the case of hash characters inside quoted strings)?

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

There is a logging initialization function used for the test programs
that may do most of what you want.

However, I think the logging was modified for BIND 10 so that log
messages were stored until the logging configuration was read, after
which the stored messages were output using that configuration. (See
the "Buffing Logger Appender", src/lib/log/buffer_appender_impl.h)

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

Sensible suggestion.

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

Agreed - if we ultimately decide we don't need them, we can always get
rid of them later.

> 12. Shell script to start/stop Kea4,Kea6 and D2 There will be a
> script that will start, stop and reconfigure the daemons. It will
> be rather simple. Its only job will be to pass config file to each
> daemon and remember its PID file, so sending signals would be
> possible (for config reload or shutdown). Optionally, it could
> also print out a status based on PID, but that may be tricky to
> implement in a portable way.

OK.

Stephen