... | ... | @@ -94,6 +94,10 @@ CM begins the configuration dry run using the `config-test` command. The Kea ser |
|
|
|
|
|
### Hooks Case
|
|
|
|
|
|
Consider another sequence diagram:
|
|
|
|
|
|
![CMSubnet4Update.svg](uploads/8b477395b4a2fdb577975716d7919702/CMSubnet4Update.svg)
|
|
|
|
|
|
When a user begins a configuration update, CM locks the configuration to protect it from concurrent modifications. CM retrieves the latest configuration from Kea using the `config-get` command or by reading the configuration file. If it differs from the current revision, CM creates a new revision.
|
|
|
|
|
|
In this scenario, the user updates an existing subnet rather than the entire configuration. Thus, CM extracts the subnet information from the configuration and returns it to the user. The user applies the updated subnet.
|
... | ... | @@ -102,8 +106,6 @@ The CM sends the `subnet4-update` command to the Kea server. The CM subsequently |
|
|
|
|
|
Besides saving the new configuration revision, the CM also creates a reverse `subnet4-update` command and saves it in the database. The reverse command allows for getting back to the previous configuration without full Kea reconfiguration (using `config-set` command). The reverse commands are stored in the JSON format next to the current configuration revision.
|
|
|
|
|
|
![CMSubnet4Update.svg](uploads/8b477395b4a2fdb577975716d7919702/CMSubnet4Update.svg)
|
|
|
|
|
|
### Config Backend Case
|
|
|
|
|
|
![CMRemoteSubnet4Set.svg](uploads/5a5059d30158b698e4b83475ff5f1ac4/CMRemoteSubnet4Set.svg)
|
... | ... | |