... | ... | @@ -4,7 +4,25 @@ As of late 2021, Stork is able to monitor Kea configuration, but not able to cha |
|
|
|
|
|
## Use cases
|
|
|
|
|
|
TBD
|
|
|
UC1: **Basic** - This is the most basic use case. There is existing Kea deployment with some configuration already done by the sysadmin. The configuration is stored in a local config file. Stork server and agent are deployed. The configuration is then pulled into Stork. The sysadmin now wants to manage its configuration using Stork. Once a change is applied in Stork, it should be deployed to a single Kea instance.
|
|
|
|
|
|
UC2: **HA** - This is similar to the basic configuration, except there is a pair of HA servers. They both share mostly the same configuration with the same shared networks, subnets and options, except some differences between partners (different pools, server name). The sysadmin now wants to manage its configuration using Stork. Once a change is applied in Stork, it should be deployed to both HA partners.
|
|
|
|
|
|
UC3: **Config Backend** - An existing Kea deployment is using Config Backend, which stores subnets, pools, and options in a MySQL database. The Stork server and agents are deployed and from now on the configuration should be managed with Stork.
|
|
|
|
|
|
UC4: **Fresh deployment** - This is a greenfield deployment. Stork is deployed with new Kea with minimal (ca, logging only) configuration. It should be possible to define essential (networks, subnets, pools, reservations, options) in Stork and then push the configuration to Kea.
|
|
|
|
|
|
UC5: **Virtualization** - This is a logical extension of the fresh deployment scenario. This is addressed at large deployments. They want to have centralized configuration storage (Stork or CB) and spin up new Kea VMs easily. If the existing Kea instances are not able to keep up, more instances should be created and Stork should be able to push configuration reasonably easily.
|
|
|
|
|
|
## Configuration aspects
|
|
|
|
|
|
Kea configuration is incredibly complicated. It is unlikely that every knob would get a graphical representation in Stork. However, there are some configuration elements that are more important than others. The primary determining factor is frequency of changes. For example, adding or changing new host reservation is typically a frequent event, often happening many times per day. On the other hand, network interface is something that's typically set up once and then never changed. The following list is a recommended implementation order for the management capabilities:
|
|
|
|
|
|
1. host reservations (HRs are used by all deployment sizes)
|
|
|
2. subnets (larger deployments add subnets frequently)
|
|
|
3. pools (technically, tweaking pools is more frequent than subnets, but to manage pools, one needs to manage subnets subnets first)
|
|
|
4. shared networks (it's a popular feature, but there are many deployments that don't use it at all)
|
|
|
5. leases (every deployment uses leases, but there are very few actual practical scenarios, where admin needs to manually do anything with leases)
|
|
|
|
|
|
## Problems
|
|
|
|
... | ... | |