A proposal for Kea configuration design

Wed Apr 30 14:49:18 UTC 2014

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
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev
> 