Commit ba5dc889 authored by Tomek Mrugalski's avatar Tomek Mrugalski 🛰
Browse files

[3396] Changes after review:

 - Configuration backend description updated
 - ChangeLog entry updated
parent bcdb6c33
7XX. [doc] tomek
Developer's Guide updated with pointers updated from BIND10 to
Kea.
Developer's Guide updated to Change BIND 10 references to Kea.
(Trac #3396, git tbd)
791. [func] tmark
......
......@@ -60,17 +60,18 @@ of Kea.
The following steps are needed to add new configuration backend (it is assumed
that the modified component is DHCPv4. Similar approach applies to other
components):
components: DHCPv6 or D2):
-# Modify AC_ARG_WITH(kea-config,...) macro in configure.ac
-# Add your own AM_CONDITIONAL(CONFIG_BACKEND_FOO, ...) macro in configure.ac
-# Add your own conditional AC_DEFINE(CONFIG_BACKEND_FOO, ...) invocation
in configure.ac
-# Modify sanity check in configure.ac to allow your configuration backend name.
-# Modify the sanity check in configure.ac to allow your configuration backend name.
-# Modify src/bin/dhcp4/Makefile.am to include your own backend
implementation (e.g. foo_controller.cc).
-# Write your own implementation of isc::dhcp::ControlledDhcpv4Srv::init(),
isc::dhcp::ControlledDhcpv4Srv::init() and isc::dhcp::ControlledDhcpv4Srv::cleanup().
isc::dhcp::ControlledDhcpv4Srv::init() and isc::dhcp::ControlledDhcpv4Srv::cleanup()
and put it in foo_controller.cc
Optionally you can also:
......@@ -83,20 +84,21 @@ Optionally you can also:
The following are some considerations that shaped the design of the configuration
backend framework.
-# A new parameter called --with-kea-config will be implemented in the
configure script. It will allow the selection at compilation time of how the
servers will be configured. For the next 2-3 months (until around June 2014),
there will be two values: JSON (read from file) and BUNDY (use the BUNDY/BIND10 framework).
Once the file based configuration is implemented and the Kea team is ready to switch
(i.e. enough confidence, Forge tests updated for new configuration
mechanism), the Bundy/BIND10 framework will be removed from the Kea repository. Other projects
(e.g. Bundy) who want to maintain it, are advised to just revert the single
commit that will bring the Bundy framework back to their repositories.
-# A new parameter called --with-kea-config was implemented in the
configure script. It allows the selection at compilation time of how the
servers will be configured. Currently (June 2014),
there are two values: JSON (the default, read configuration from a JSON file)
and BUNDY (use the BUNDY/BIND10 framework). The Bundy/BIND10 framework was removed
from the Kea repository. Other projects
(e.g. Bundy) who want to maintain Bundy framework, are advised to maintain
the framework in their repositories, import Kea modules and compile them
with Bundy backend.
This switchable backend concept is quite simple. There are just different
implementations of ControlledXSrv class, so it is a matter of compiling/linking
implementations of ControlledXSrv class, each backend keeping its code
in a separate file. It is a matter of compiling/linking
one file or another. Hence it is easy to remove the old backend (and for
Bundy to keep it if they desire so). It is also easy for other
organizations to add and maintain their own backends (e.g. LDAP).
external projects, like Bundy, to keep it if they desire so). It is also easy
for other organizations to add and maintain their own backends (e.g. LDAP).
-# Each backend must use the common code for configuration and command
processing callbacks. They all assume that JSON formatted parameters are sent
......@@ -113,13 +115,15 @@ backend framework.
-# A command handler needs to be added for reading the configuration from a
file. Its main responsibility is to load the configuration and process
it. The JSON backend must call that handler when starting up the server.
This is implemented in configure() function in kea_controller.cc files
in src/bin/dhcp4 and src/bin/dhcp6 directories.
-# Extend the existing JSON parser. The current JSON parser in @ref
isc::data::Element::fromJSON() needs to be extended to allow optional
preprocessing. For now that capability will simply remove whole-line
preprocessing. For now that capability simply removes whole-line
comments staring with the hash character, but it is expected to grow over
time (in-line comments and file inclusions are the obvious envisaged
additions).
additions). This is implemented in @ref isc::data::Element::fromJSONFile.
-# Implement a common base class for the Kea4, Kea6, and D2 servers. Some
operations will be common for all three components: logger initialization,
......@@ -128,16 +132,19 @@ backend framework.
isc::dhcp::Dhcpv6Srv "Dhcpv6Srv" and the @ref isc::d2::D2Controller
"D2Controller" classes can use. It is expected that the base class (@ref
isc::dhcp::Daemon) will be a small one but will grow over time as the code is
unified.
unified. This has been implemented in @ref isc::dhcp::Daemon.
-# A way is needed to initialize stand-alone logging (i.e. each
Kea component will initialize it on its own).
-# The current format of the BIND10 configuration file, b10-config.db will be
retained as the configuration file format. This is slight change
from the BIND10 days, as then a subset of the configuration was received by
the daemon processes. To take a specific example, the following is how
b10-config.db looks today:
-# The current format of the BIND10 configuration file (BIND 10 stored its
configuration in (installation directory)/var/bind10/b10-config.db) will be
retained as the configuration file format. Its actual naming is now arbitrary
and left up to the user (it is passed as a parameter to the -c command line
option). From the implementation perspective, this is slight change
from the BIND10 days, as back then a subset of the configuration was received by
the daemon processes. Nowadays the whole configuration is pased. To take a
specific example, the following is how b10-config.db looks today:
@code
{
"Init": { ... }
......@@ -186,4 +193,7 @@ backend framework.
- this could also decide if D2 should still be running or not, and react accordingly (post 0.9)
-# Stop the processes in an orderly fashion
-# Perhaps return status of each process
This script has been implemented in src/bin/keactl/keactl.
*/
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment