Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Re: A proposal for Kea configuration design (Stephen Morris)
2. Re: A proposal for Kea configuration design (Thomas Markwalder)
3. Re: A proposal for Kea configuration design (Tomek Mrugalski)
----------------------------------------------------------------------
Message: 1
Date: Mon, 05 May 2014 20:01:33 +0100
From: Stephen Morris <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: [email protected]
Subject: Re: A proposal for Kea configuration design
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
> 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
------------------------------
Message: 2
Date: Mon, 05 May 2014 15:17:36 -0400
From: Thomas Markwalder <[email protected]>
To: Stephen Morris <[email protected]>, Tomek Mrugalski <[email protected]>
Cc: [email protected]
Subject: Re: A proposal for Kea configuration design
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 5/5/14, 3:01 PM, 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).
(Tomek has already seen my comment, below, so this is for others:)
I have some issues with this. Maybe it is just the semantics. What you
are selecting between here is not a configuration mechanism, but whether
or not Kea components can run as BIND10 modules. So really you are
selecting between run time topologies more than alternate configuration
mechanisms. There is more to BIND10 participation than just
configuration, it governs process startup, shutdown, restarts on crash,
etc.
Unlike the Lease Database, which has an API, we don't really have an API
for configuration. Each server has its information model (Interface,
Subnets, Pools...) and our parsing creates it from JSON. If we want to
use XML or LDAP, somehow one has to construct the same information model
but from an alternate from of configuration data. This is something that
would require a good deal of thought and design. Also, If "back end"
choices mean different top level source files than aren't they mutually
exclusive?
Rather than have a switch and multiple source files, why not simply use
the stand-alone command line option to test "From file config" and leave
the bind10 session code in place until we are ready to take it out. This
way one build lets you run either way and we aren't creating temporary
files and configuration options.
------------------------------
Message: 3
Date: Tue, 06 May 2014 11:34:19 +0200
From: Tomek Mrugalski <[email protected]>
To: Stephen Morris <[email protected]>
Cc: [email protected]
Subject: Re: A proposal for Kea configuration design
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
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
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 2, Issue 2
*************************************
