... | ... | @@ -12,9 +12,6 @@ UC2: **Existing Kea config file** - There is an existing Kea deployment with som |
|
|
|
|
|
UC3: **HA, local configuration** - This is similar to UC2, except there is a pair of HA servers already configured using local configuration files. The Kea servers share most of their configuration (the same shared networks, subnets and options), but there are some differences between partners (different pools, server names). The sysadmin now wants to manage the configuration of both servers using Stork. Once a change is applied in Stork, it should be deployed to both HA partners. Also, see related UC9.
|
|
|
|
|
|
> It seems like this is the obvious use case for the config backend, isn't it? where the shared data is in the config backend? I think we need to prioritize either reading/modifying individual local config files or the config backend. I think recognizing where segments of multiple separate configuration are the same is a complicated advanced task, so if we want to manage shared configuration elements, we could require those are in the config backed.
|
|
|
|
|
|
> I am not sure if this is meant to be something other than, multiple Kea servers sharing a configuration backend. Is there some way that HA pairs are special here?
|
|
|
|
|
|
UC4: **Config Backend** - An existing Kea deployment is using the Config Backend, which stores subnets, pools, and options in a MySQL database. There will be multiple Kea servers, likely sharing some data in the config backend. Other configuration information is stored in the config file on the individual Kea servers. The Stork server and agents are deployed and *from now on the Kea configurations should be managed with Stork*.
|
|
|
|
... | ... | |