From: Tomek Mrugalski Date: Wed, 9 Jul 2014 11:57:56 +0000 (+0200) Subject: [3396] Changes after review: X-Git-Tag: trac3482_base~82^2~1 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=ba5dc8895f03987095eb3828f5dbe38e8dd8d6bd;p=thirdparty%2Fkea.git [3396] Changes after review: - Configuration backend description updated - ChangeLog entry updated --- diff --git a/ChangeLog b/ChangeLog index 14a1cec382..a36de4ad6b 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,6 +1,5 @@ 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 diff --git a/doc/devel/config-backend.dox b/doc/devel/config-backend.dox index 86d7057ad2..005aad80a3 100644 --- a/doc/devel/config-backend.dox +++ b/doc/devel/config-backend.dox @@ -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. + */