... | ... | @@ -112,8 +112,22 @@ Besides saving the new configuration revision, the CM also creates a reverse `su |
|
|
|
|
|
## Configuration Versioning
|
|
|
|
|
|
Stork holds a current Kea daemon configuration in the `kea_daemon` table. It replaces this configuration every time the state puller detects a configuration change. Once Stork gains new Kea configuration capabilities, the administrators should use Stork to apply configuration changes. However, Stork's configuration capabilities will be initially somewhat limited. In addition, we can't guarantee that someone with direct access to the Kea configuration won't apply a configuration change by editing the configuration file - either in case of some emergency or by mistake. Stork must deal with out-of-bound configuration updates smoothly.
|
|
|
|
|
|
We're going to keep the existing puller mechanism to apply detected configuration changes. Suppose Stork pulls a configuration change while a user edits the configuration in the UI. The pulled configuration change takes precedence in that case, and Stork should notify the user that the configurations diverged. Such a conflict can cause a user to start over his changes, but we assume it will be very infrequent.
|
|
|
|
|
|
We will introduce a new table, `kea_config_revision`, holding previous Kea configuration revisions. Should we maintain old configuration revisions for other application types in the future, we will introduce dedicated tables for them. It is practical to have dedicated tables for different applications because many things may differ between them - starting from the configuration formats, ending on SQL foreign keys referencing specific tables. In addition, the number of different applications will be relatively small, so adding a handful of tables is not a problem.
|
|
|
|
|
|
The current configuration for a daemon will still be stored in the `kea_daemon` table. A new trigger will copy the configuration to the `kea_config_revision` table upon its update. The copied configuration will be assigned an incrementing id in the `kea_config_revision` table. The `user_id` will be copied as well to indicate who applied the change. The `user_id` will be NULL if an out-of-bound change is detected.
|
|
|
|
|
|
The `reverse_commands` value is only set when a user applies a configuration change using commands exposed by the hook libraries (e.g., `subnet_cmds`). In this case, the CM can store one or more commands reverting to this revision. In this case, the revision will contain both the entire configuration and the commands reverting to it from the later revision. To revert to this configuration from the later one, the CM may first try using the reverse commands. If it fails or is not feasible, it should fall back to the stored configuration and the `config-set` command instead.
|
|
|
|
|
|
The following picture shows the new `kea_config_revision` table, the updated `kea_daemon` table, and the `system_user` table now referenced from the `kea_daemon` table.
|
|
|
|
|
|
![kea_config_revision](uploads/cf6c6f2b0a90d4151f1ccb2aa58f1581/kea_config_revision.png)
|
|
|
|
|
|
Here is the corresponding SQL migration (including functions, triggers, etc.):
|
|
|
|
|
|
```sql
|
|
|
ALTER TABLE kea_daemon ADD COLUMN user_id BIGINT;
|
|
|
ALTER TABLE kea_daemon ADD CONSTRAINT
|
... | ... | |