Redesigning Configuration Manager (CfgMgr) class

Marcin Siodelski marcin at isc.org
Wed Aug 27 08:10:00 UTC 2014


With the number of configuration parameters that Kea currently supports
and given that each new feature may come with a collection of new
parameters, I think it is a high time to try to make a redesign of the
Kea Configuration Manager (src/lib/dhcpsrv/cfg_mgr.cc).

Issues:
- Not only configuration manager is a storage for the server
configuration but also provides means for validation of parameters
(throws exceptions when data element is wrong) and accessors for each of
the parameters. With the number of configuration parameters growing we
will be facing the problem of the overgrown CfgMgr class.

- CfgMgr doesn't provide any means for building new configuration while
still using current configuration. A change to any of the configuration
parameters affects the current configuration.

- There is no way to rollback the configuration. If you're building a
new configuration you have to keep it aside until you're confident that
the whole configuration is valid. Keeping data integrity should be a
role of the Configuration Manager.

- Applying a new configuration is not atomic. In order to create a new
configuration you have to call a bunch of modifier functions one-by-one.
While you do it, the data integrity is affected (partially have an old
configuration, partially new).

- CfgMgr always allows Read-Write operations. As a result the
configuration can be modified from any place of the code. In fact, the
configuration should only be possible when you configure the server.


In my opinion we should try to address issues listed above as soon as
possible because we're going to add new configuration parameters as a
result of implementing new features such as: client classification,
DHCPv4 over DHCPv6 implementation, new hooks etc. It will be a waste of
time to add them to the CfgMgr following a current model and later re-do it.

I'd like to discuss some proposals for changes to the CfgMgr that
address some of these issues.

This is the ticket for this work: http://kea.isc.org/ticket/3534

We already have a Configuration class (src/lib/dhcpsrv/configuration.h)
which holds the logger configuration. I think that Tomek's intent to
create this class was that multiple instances of configuration could be
held by the CfgMgr. At present, only one instance is held but we could
easily extend CfgMgr to hold the list of Configuration objects. The
reason to keep it in the list is that we can quickly remove former
configurations and keep, say, last 10 of them. We could even make it
configurable how many last configurations are kept.

When the configuration is committed, the most recent configuration on
the list should keep the current configuration. There should be an
accessor method which returns this configuration as a read only object
or a read-only pointer to a read-only object.

When the server is being configured, the configubration parsers should
obtain a fresh copy of the Configuration object. This object should be
Read-Write. A fresh copy is returned by the CfgMgr when requested. If
the object doesn't exist it is created by the CfgMgr so as the caller
doesn't have to worry if it is valid (e.g. null pointer etc.). If the
new configuration had already been created (by the previous calls) it is
returned. This way, when the new configuration is built from different
parts of the code and the Configuration object doesn't have to be passed
back and forth between functions, but rather functions can just query
the CfgMgr singleton for the "staging" configuration.

When configuration is ready, the commit function can be called. This
function should be exception free and it should solely switch the
pointer of the current configuration to the new configuration. At this
point the "staging" configuration becomes a "current" configuration.

At commit time the most ancient configuration is removed from the list,
unless the threshold of the number of configurations held hasn't been
reached. This would be a base for future extensions that the user can
revert to any previously working configuration.

There should be a function in the CfgMgr which rollbacks changes, i.e.
removes the "staging" configuration if it exists.


Note that the use of "staging" configuration eliminates a need for
keeping an additional parser context which we currently use for keeping
data integrity. This also eliminates a need for parsers to have build
and commit phases. The commit is an atomic operation executed at the
very end of the configuration parsing and it is always exception free.
In build phase exceptions are possible and build() functions of
configruation parsers operate on the "staging" configuration which they
query from the CfgMgr. There will also be no need to provide storages
for configuration parsers because configuration parsers will use the
"staging" configuration as a storage.

Overall, I am pretty confident that those simple changes will reduce the
complexity of the configuration parsers which is a pain in the back
right now.

Feedback appreciated as well as additional requirements.

Marcin



More information about the kea-dev mailing list