From: Ben Scott Date: Fri, 9 May 2025 13:33:32 +0000 (-0400) Subject: [#3881] Move "Incompatibilities" further up X-Git-Tag: Kea-3.0.0~45 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=09d730ac519fed3d1bc8427b7aa0cada3f86c579;p=thirdparty%2Fkea.git [#3881] Move "Incompatibilities" further up --- diff --git a/doc/sphinx/arm/config-backend.rst b/doc/sphinx/arm/config-backend.rst index cdf46d132e..de9f874b8b 100644 --- a/doc/sphinx/arm/config-backend.rst +++ b/doc/sphinx/arm/config-backend.rst @@ -78,6 +78,23 @@ The general intent is for the CB to be integrated with external software. Please do not define ``config-databases`` unless you have done the necessary preparation work. +Incompatibilities +^^^^^^^^^^^^^^^^^ + +Use of the :ischooklib:`libdhcp_subnet_cmds.so` hook with the CB is +contraindicated. The API commands starting with ``subnet`` all modify the +in-memory configuration of Kea. The only way to save that config would be to +write out a JSON config file. That would conflict with any subnets defined by +the CB. Use :ischooklib:`libdhcp_cb_cmds.so` to manage the +subnets information in the database instead. + +The Stork management suite does not currently support the CB. Stork operates +by direct configuration modification, with accompanying ``config-write`` of +the JSON config file. That would create duplicate definitions vs the CB. +Support for the CB is planned for a future release of Stork. + +In certain carefully-controlled scenarios, it may be possible to use these tools with the CB. Namely, if they are used in strictly "read-only" fashion, to retrieve Kea information, but never to modify it. However, no protection against accidental modification is provided, so this is not recommended. + Implementation ^^^^^^^^^^^^^^ @@ -126,23 +143,6 @@ structures are replaced entirely. For example, if client classes are defined in the CB database, the DHCP server disregards any client classes defined in the JSON file. -Incompatible Software -^^^^^^^^^^^^^^^^^^^^^ - -Use of the :ischooklib:`libdhcp_subnet_cmds.so` hook with the CB is -contraindicated. The API commands starting with ``subnet`` all modify the -in-memory configuration of Kea. The only way to save that config would be to -write out a JSON config file. That would conflict with any subnets defined by -the CB. Use :ischooklib:`libdhcp_cb_cmds.so` to manage the -subnets information in the database instead. - -The Stork management suite does not currently support the CB. Stork operates -by direct configuration modification, with accompanying ``config-write`` of -the JSON config file. That would create duplicate definitions vs the CB. -Support for the CB is planned for a future release of Stork. - -In certain carefully-controlled scenarios, it may be possible to use these tools with the CB. Namely, if they are used in strictly "read-only" fashion, to retrieve Kea information, but never to modify it. However, no protection against accidental modification is provided, so this is not recommended. - Custom Options ^^^^^^^^^^^^^^