This is a working document and is subject to reviews and substantial changes!
Use cases envisioned include:
- due to utilization or network expansion, the operator decides to add another DHCP server. The operator wants to spin up a server by copying and modifying an existing server configuration.
- a server fails, and the operator wishes to clone that server on a new machine
- a server's configuration becomes somehow corrupted, perhaps by a local change, and the operator wishes to restore a prior working configuration
- the operator needs to make a change (the same change) to multiple servers and wishes to make the change(s) in one centralized place. This is one key use case for centralizing all the host reservations.
- the operator needs to make a change that requires altering several servers' configuration. This might include renumbering some subnets, or moving a subnet from one machine to another, or establishing an HA pair.
- the operator needs tight control over access control to DHCP server configuration, and therefore wishes to prevent local configuration and require all configuration come from a single centralized place, which has granular permission and access controls
- The operator requires centralized storage of running configurations for audit and backup purposes.
Terminology in this Document
The feature of Kea which this document describes requirements of is called Configuration Backend or CB. This follows naming conventions used for other similar features already present in Kea, i.e. Lease Database Backend, Host Reservations Backend. While the word "backend" often relates to a module of the software that is capable of communicating with an external database and providing information to other modules of the system via some kind of API, in the context of this document the Configuration Backend means the entire feature of Kea providing database storage for configuration, methods to store and fetch the data from the databases, commands to manage the configuration information etc.
Kea Configuration Backend (CB) Requirements
- CB SHOULD be supported by all Kea daemons, i.e. DHCP servers, Control Agent and D2
- CB MUST be supported for all existing database backends, i.e. MySQL, Postgres and Cassandra
- CB MUST be able to store specific parts of the configuration in the database and other parts in the file or other database.
- CB MUST be able to store entire configuration for each Kea daemon (desirable, not sure why this has to be entire configuration - we have centralized configuration for host reservations, perhaps we add subnets and shared networks, but maybe interfaces could be a later addition?)
- CB MUST be able to store configuration for all Kea daemons in the same database.
- CB MUST be able to store configuration for respective Kea daemons in separate databases.
Kea servers MUST be able to learn about configuration changes applied to the database instance they are using by querying that database without a need for any additional administrative action (such as command to make the server reload its configuration).
- It MUST be possible to control whether config-get returns the configuration from the Kea config-file or retrieves appropriate configuration from the databases and merges it with the configuration in the config file.
- config-set MUST not overwrite the configuration in the config file if this config refers to the databases storing any part of the configuration. It MUST be possible to overwrite the configuration when explicitly requested via new parameter or another command.
- config-set MUST allow for overwriting the configuration file, without affecting the configuration in the databases.
- config-set MUST allow for overwriting the configuration stored in the databases (follow references to the databases from the configuration file).
It MUST be possible to select subnet by querying the subnets present in the database (database query per packet)