... | ... | @@ -8,7 +8,7 @@ Each of the following use cases emphasizes certain aspect of the configuration m |
|
|
|
|
|
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.
|
|
|
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. Also, see related UC9.
|
|
|
|
|
|
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.
|
|
|
|
... | ... | @@ -22,6 +22,8 @@ UC7: **Audit** - In a larger deployment, there is a group of admins. There shoul |
|
|
|
|
|
UC8: **Planning changes** - In more complex environments, larger and strategic changes are planned in advance. It should be possible to prepare new configuration, but not apply it immediately and define a point in time where it should be deployed. Examples: renumber to new ISP, retire old printer/router/etc.
|
|
|
|
|
|
UC9: **Enabling HA** - This is somewhat related to UC2. The initial configuration is a stand-alone Kea server. The sysadmin now wants to enable HA and needs to come up with a configuration for the second server. Stork should allow extending stand-alone config into HA-enabled mode and then clone it (with the necessary changes) to the second server.
|
|
|
|
|
|
## 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:
|
... | ... | |