A proposal for Kea configuration design

[Tomek Mrugalski]

On 05.05.2014 21:01, Stephen Morris wrote:
>> 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.

>> 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.)
I think the code for calculating TSIG is already there in libdns. DNS
components (xfrin) already support incoming zone updates signed with
TSIG. Anyway, that's not something we need to solve here. This is pretty
important piece of the puzzle, so we'll have dedicated meeting (or two)
to discuss this.

>> 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)?
Whole-line comments, just because they were easier to implement. When
talking about inline comments, you need context. Are you in a string? If
you are, then ignore them and continue parsing. Even more tricky are
C-style comments, which can span multiple lines. That's all doable, but
I thought that for now we can stick with the simplest: # in the first
column.

>> 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.
I looked at it and it is not sufficient. By default it prints out
nothing, so you'd get completely mute server. That's not what we want.
If we change it, then suddenly our tests become very verbose.

Anyway, there are 2 aspects here:
9a) parse part of the config file that describes what log where.
9b) apply that to actually configure log4cplus

> 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)
Yes, and there is more. Some sort of locking mechanism was implemented,
so when two processes try to log, one of them locks and waits for the
other to complete. See Shane's post from 2 days ago:
http://lists.bundy-dns.de/pipermail/bundy-hackers/2014-May/000010.html

I was not aware that there are locking mechanisms implemented in liblog.
It would be interesting to run a performance test on memfile (as it is
the fastest backend), then modify to liblog to not log anything and then
repeat. It should show us the impact on performance of the logging
mechanism overhead.

BTW We're potentially interested in the changes Bundy guys plan to do in
logging.

Tomek