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. A proposal for Kea configuration design (Tomek Mrugalski)
2. Re: A proposal for Kea configuration design (Tomek Mrugalski)
3. Re: A proposal for Kea configuration design (Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Wed, 30 Apr 2014 16:02:19 +0200
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: A proposal for Kea configuration design
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
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?
Tomek
------------------------------
Message: 2
Date: Wed, 30 Apr 2014 16:49:18 +0200
From: Tomek Mrugalski <[email protected]>
To: [email protected]
Subject: Re: A proposal for Kea configuration design
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Oh, forgot about the wrapper around.
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. The minimum set of commands would be:
a: Start the processes
- eventually based on config, initially start them all
- it could launch a nanny script which restarts them on a crash
(past 0.9)
b: Prompt the processes to reload configuration
- for now it will be a matter of sending singal to the right process
- this could also decide if D2 should still be running or not,
and react accordingly (past 0.9)
c: Stop the processes in an orderly fashion
d: Perhaps return status of each process
On 30.04.2014 16:02, Tomek Mrugalski wrote:
> 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?
>
> Tomek
> _______________________________________________
> kea-dev mailing list
> [email protected]
> https://lists.isc.org/mailman/listinfo/kea-dev
>
------------------------------
Message: 3
Date: Thu, 01 May 2014 09:06:22 +0000
From: Francis Dupont <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: [email protected]
Subject: Re: A proposal for Kea configuration design
Message-ID: <[email protected]>
Tomek Mrugalski writes:
> 4. After 0.9, we will design some form of secure socket that we'll be
> able to send commands over.
=> please don't use SSL/TLS (or similar protocol) to provide the "secure"
in this. I believe today I don't need more arguments to explain the
reason...
Regards
Francis Dupont <[email protected]>
PS: I suggest a locally bound socket: it offers the same security (or
better :-) than a TLS code with a private key in a file.
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 2, Issue 1
*************************************
