... | ... | @@ -70,13 +70,11 @@ We have to address an essential requirement to track the configuration changes a |
|
|
- 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.
|
|
|
To be able to revert to a previous configuration, Stork must maintain a trace of the applied configuration changes between the revisions. 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 weak when the `subnet_cmds` hook library is used for subnets and shared networks management. In this case, from the performance perspective, it would be better to revert the changes by sending appropriate commands via these hooks libraries, rather than causing the server to fully re-configure. However, using the `config-set` command to revert the changes applied via the hook library can still be treated as a last resort. It is not applicable for the configuration backend case because the `config-set` command does not affect the configuration in the database.
|
|
|
|
|
|
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.
|
|
|
Applying changes to the configuration becomes a complex process comprising multiple steps ensuring proper configuration versioning and keeping the data integrity. A new component, Configuration Manager (CM), will have this responsibility. It will provide the locking/unlocking mechanism preventing concurrent access to the same configuration by multiple users. It will also make available the identity of the user currently editing the configuration.
|
|
|
|
|
|
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.
|
|
|
Further sections describe in more detail the CM's behavior in different configuration scenarios.
|
|
|
|
|
|
### Configuration File Case
|
|
|
|
... | ... | |