... | ... | @@ -6,6 +6,8 @@ As of late 2021, Stork is able to monitor Kea configuration, but not able to cha |
|
|
|
|
|
Each of the following use cases emphasizes certain aspect of the configuration management. In many actual deployments, several use cases may be applicable.
|
|
|
|
|
|
UC2 is a priority regarding order of development.
|
|
|
|
|
|
UC1: **Fresh deployment** - This is a greenfield deployment. Stork is deployed with new Kea with minimal configuration only (ca, logging). It should be possible to define the remaining parameters (networks, subnets, pools, reservations, options) in Stork and then push the configuration to Kea. There should be some feedback to the administrator as the configuration is validated, applied to the Kea server and saved in the local Kea config file.
|
|
|
|
|
|
UC2: **Existing Kea config file** - There is an existing Kea deployment with some configuration already done by the sysadmin. This current running configuration is stored in a local config file. Stork server and agent are deployed. The sysadmin now wants to view and change this Kea configuration using Stork. Once a change is applied in Stork, it should be deployed to this existing single Kea instance. It is important to ensure that the local configuration file has not been changed after Stork retrieved it, and before Stork pushes the updates, particularly if Stork is only pushing a partial configuration.
|
... | ... | |