... | ... | @@ -30,22 +30,6 @@ Kea configuration is incredibly complicated. It is unlikely that every knob woul |
|
|
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
|
|
|
|
|
|
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: Persistence. Once the configuration is pushed, the change should persist after crash, power failure and reboots. Likely `config-write` could be used to store the updated config locally. 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
|
|
|
|
|
|
TBD |
|
|
\ No newline at end of file |