mir/kea
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-09-01 14:35:29 +00:00
Code Issues Releases Wiki Activity

[#3881] Major edit of "Duplicate Definitions"

Browse Source
This commit is contained in:
Ben Scott
2025-05-09 09:29:31 -04:00
committed by Marcin Siodelski
parent b17af41f9a
commit ffcf7bb3ae
1 changed files with 18 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
doc/sphinx/arm/config-backend.rst
View File

@@ -106,28 +106,25 @@ management commands for config backends.
Duplicate Definitions Duplicate Definitions
^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^
We strongly recommend against duplication of configuration information We strongly recommend against storing configuration information in both the
in both the file and the database. For example, when specifying subnets config file and the CB database. In other words, do not use both JSON config
for the DHCP server, please store them in either the configuration backend files (like ``kea-dhcp4.conf``) and CB to configure the same items. Ideally,
or in the configuration file, not both. Storing some subnets in the database when using the CB, the Kea config files should contain the absolute bare
and others in the file may put users at risk of potential configuration minimum necessary, with everything else coming from the CB.
conflicts. Note that the configuration instructions from the database take
precedence over instructions from the file, so parts of the configuration
specified in the file may be overridden if contradicted by information in
the database.
Although it is not recommended, it is possible to specify certain parameter Using both CB and JSON as a source of configuration risks conflicting
types both in a configuration file and the database. For example, a subnet definitions, which is confusing at best, and usually leads to undesired
can be specified in the configuration file and another subnet in the database; behavior.
in this case, the server will use both subnets. DHCP client classes, however,
must not be specified in both the configuration file and the database, even if In the event of a conflict, configuration instructions from the CB database
they do not overlap. If any client classes are specified in the database generally take precedence over instructions from a JSON file.
for a particular DHCP server, this server will use these classes and ignore
all classes present in its configuration file. This behavior was introduced In certain carefully-controlled scenarios, it may be technically possible to
to ensure that the server receives a consistent set of client classes use both. For example, defining one subnet in a JSON file and a second
specified in an expected order with all inter-class dependencies fulfilled. (different) subnet in the CB database would not conflict. However, other
It is impossible to guarantee consistency when client classes are specified structures are replaced entirely. For example, if client classes are defined
in two independent configuration sources. in the CB database, the DHCP server disregards any client classes defined in
the JSON file.
Incompatible Software Incompatible Software
^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^