... | ... | @@ -4,6 +4,8 @@ As of late 2021, Stork is able to monitor Kea configuration, but not able to cha |
|
|
|
|
|
## Use cases
|
|
|
|
|
|
Each of the following use cases emphasizes certain aspect of the configuration management. In many actual deployments, several use cases may be applicable.
|
|
|
|
|
|
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.
|
... | ... | @@ -14,6 +16,10 @@ UC4: **Fresh deployment** - This is a greenfield deployment. Stork is deployed w |
|
|
|
|
|
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.
|
|
|
|
|
|
UC6: **Reverting changes** - The sysadmin implemented a change and users started complaining. He/she would like to compare to earlier configuration and revert changes, effectively rolling back to old configuration.
|
|
|
|
|
|
UC7: **Audit** - In a larger deployment, there is a group of admins. There should be an audit trail of who implemented given change. There should be some history of the configuration elements being changed.
|
|
|
|
|
|
## 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:
|
... | ... | @@ -26,7 +32,19 @@ Kea configuration is incredibly complicated. It is unlikely that every knob woul |
|
|
|
|
|
## Problems
|
|
|
|
|
|
TBD
|
|
|
This section probably fits better into initial design page.
|
|
|
|
|
|
Problem 1: How to push configuration. The whole configuration can be pushed with `config-set`. This is a reasonable initial approach and may work well for smaller deployments that do infrequent changes and the interruption is acceptable. For larger deployments, the service interruption during `config-set` becomes a problem, especially if there are many changes. For many other elements we have dedicated commands (reservation-add, subnetX-add, etc). However, depending on the deployment there may be alternatives (should subnetX-add or remote-subnetX-set be used?).
|
|
|
|
|
|
Problem 2: Storage. Once the configuration is pushed, the change should persist after crash, power failure and reboots. Likely `config-write` could be used to help. But there are some quirks. How to know where the config is supposed to be written? It depends on the startup scripts which config will be loaded. Also, what if the local system is read-only or Kea user doesn't have write permissions (which may be likely - kea running as user kea, but the configs were created and are owned by root).
|
|
|
|
|
|
Problem 3: Reverting changes. How many older versions should we keep? In many cases they will differ with only one or two elements. Also, if we revert from config B back to A, do we want to keep configuration B? One reason for reverting is that there's something wrong with the new configuration, so it may be tweaked a little bit and then applied.
|
|
|
|
|
|
Problem 4: Applying complex changes. Imagine a situation that there are 3 client classes used in many subnets. The configuration is being simplified to just two classes. First, the class definitions should be updated and then many (say 100) subnets should be updated as well. How to do such a change? All at once, incrementally? Should there be something like staging config, so multiple edits in many places could be done and then all applied at once?
|
|
|
|
|
|
Problem 5: Scheduling changes. This is useful for large scale or business sensitive deployments or migrations. If you have a complex network and you're changing your upstream ISPs, you want to do the switch at certain low activity time, e.g. sunday 2am. The change should be planned in advance, probably reviewed by other users etc.
|
|
|
|
|
|
Problem 6: Hooks dependence. Some changes are more easily done if there's a hook available for it. The first aspect is what if the hook is present in the system, but not loaded in the config? Should this be done with two steps approach? Step 1: enable necessary hooks. Step 2: perform the actual config changes. The second aspect is where the hooks are located? Depending on the installation method, they may be in different dirs (also see somewhat related https://gitlab.isc.org/isc-projects/kea/-/issues/2101 that would make this problem a bit easier). The third aspect is that some desired hooks (host_cmds, subnet_cmds and cb_cmds in particular) are paid and may be unavailable. How to handle such situation? One viable way is to simply disable related Stork configuration capability and point to missing required hooks.
|
|
|
|
|
|
## Requirements
|
|
|
|
... | ... | |