... | @@ -64,7 +64,19 @@ The partial configuration stored in the configuration file is herein called a so |
... | @@ -64,7 +64,19 @@ The partial configuration stored in the configuration file is herein called a so |
|
At the time of writing this design, the Stork server has no access to any of the Kea source configurations. The `stork-agent` accesses the Kea Control Agent's source configuration (configuration file) to detect communication endpoints. It doesn't access any of the source configurations otherwise. In order to implement configuration management, we will need to allow access to the source configurations. Stork must not modify runtime configuration because such modifications are not permanent and may conflict with the source configurations (e.g., with the config backend).
|
|
At the time of writing this design, the Stork server has no access to any of the Kea source configurations. The `stork-agent` accesses the Kea Control Agent's source configuration (configuration file) to detect communication endpoints. It doesn't access any of the source configurations otherwise. In order to implement configuration management, we will need to allow access to the source configurations. Stork must not modify runtime configuration because such modifications are not permanent and may conflict with the source configurations (e.g., with the config backend).
|
|
|
|
|
|
## Modifying Source Configuration
|
|
## Modifying Source Configuration
|
|
TBD
|
|
|
|
|
|
We have to address an essential requirement to track the configuration changes and allow for reverting to one of the former configuration revisions. It implies that Stork has to follow the configuration changes tightly and ensure configuration data integrity between Kea and Stork. The following issues elevate the complexity of this task:
|
|
|
|
multiple users can modify a configuration, possibly applying conflicting changes,
|
|
|
|
there are different ways to modify source configurations, and depending on the one used, there are different ways to revert to a previous configuration,
|
|
|
|
settings in the configuration backend are not populated to Kea instantly - there is a time period between applying the new configuration settings (source configuration changes) and when Kea pulls them (runtime configuration changes).
|
|
|
|
|
|
|
|
To be able to revert to a previous configuration, Stork must maintain a trace of the applied configuration changes between the revisions. In the simplified scenario, the trace could comprise a series of the complete Kea configurations at all revisions. Reverting to a selected configuration could be achieved by sending the `config-set` command with that configuration. This solution is insufficient when `subnet_cmds` hook library is used for subnets and shared networks management. It is not applicable for the configuration backend case. We will analyze these scenarios further in this section.
|
|
|
|
|
|
|
|
In our simplified scenario, Stork must save the current Kea runtime configuration in the trace. Next, it must send the `config-set` command to Kea and check if it has been successful. Finally, Stork must send `config-write` command to persist the new configuration. In addition, Stork could also validate the new configuration using the `config-test` command before setting it.
|
|
|
|
|
|
|
|
All these operations should be performed in isolation to guarantee atomicity. If one of the users starts applying the configuration changes to a server, all other updates must be on hold until the changes are committed. The resulting configuration should be an input to the updates performed by the other user.
|
|
|
|
|
|
|
|
A new component, Configuration Manager (CM), will provide the mechanics for ensuring the configuration updates atomicity by locking the configuration until a timeout or until it is committed. CM will also make available the identity of the user currently performing the updates.
|
|
|
|
|
|
## Configuration Versioning
|
|
## Configuration Versioning
|
|
TBD
|
|
TBD
|
... | | ... | |