... | ... | @@ -346,3 +346,58 @@ Problem 4: **Applying complex changes**. Imagine a situation that there are 3 cl |
|
|
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.
|
|
|
|
|
|
## Comments
|
|
|
|
|
|
### @slawek 2021-02-21
|
|
|
|
|
|
> Design choice: use the command-line tool capability to manage the application remotely or install the tool on the managed application's machine and control it over the stork-agent
|
|
|
|
|
|
In my opinion, the server machine shouldn't execute any heavy and long-time tasks. These tasks should be delegated to the Stork Agents. Additionally, the Stork Server is located in a public part of a network. It should connect directly with a limited number of remote hosts for security reasons.
|
|
|
|
|
|
-----
|
|
|
|
|
|
> Modifying Source Configuration
|
|
|
|
|
|
We should primarily use the hooks to modify the Kea configuration because the Stork shouldn't be related to the Kea internals (and vice-versa).
|
|
|
|
|
|
We should extend the hooks to better cooperate with the Stork and develop new ones to cover the following use cases. It allows us to write the modification code near the Kea core. In this case, the edit commands will work correctly even if the Kea will be strongly updated or modified. The support for different Kea versions will be more straightforward because the hooks will still be the same public interface.
|
|
|
|
|
|
We should analyze the possibility of extending the hooks with a permanent update function (and maybe stacking the same function calls) to avoid using the `config-write` command. The hooks should also support the CB. It isn't a good approach to modify the Kea database directly from the Stork Server/Agent because the Stork doesn't know the Kea DB schema and out-of-schema logic.
|
|
|
|
|
|
The `config-set` should be used mainly to modify the general entries of a source configuration file (as interfaces, hooks, etc.).
|
|
|
|
|
|
-----
|
|
|
|
|
|
> dedicated command-line tools (e.g., kea-admin, psql, mysql),
|
|
|
|
|
|
It is a pleasing feature to manage the Kea databases via Stork, but it should be done using the dedicated tools that are Kea-related. It means that we should use `kea-admin` to create or migrate the database, but we shouldn't directly connect with the external MySQL, Postgres servers. It breaks the security rules (the DBs have fine-grained access rules), also Stork shouldn't be related to the Kea DB schema.
|
|
|
|
|
|
-----
|
|
|
|
|
|
> A new component, Configuration Manager (CM), will have this responsibility. It will provide the locking/unlocking mechanism preventing concurrent access to the same configuration by multiple users.
|
|
|
|
|
|
I understand that CM locks the editing only for the Stork users. It can be problematic if the customer has external tools based on hooks or direct DB access because the lock doesn't affect them.
|
|
|
|
|
|
Are we able to add a locking solution in the Kea? For example, the Stork Agent requests for edit lock. Kea responds with the edit and refresh token. Only the edit requests with a valid edit token are accepted. The edit token is a short period, but the Stork can use the refresh token to prolong the token lifetime during an edit session. If the server fails or the editing session breaks, the edit token expires, and Kea is ready to accept instant editions or request a new edit token.
|
|
|
|
|
|
-----
|
|
|
|
|
|
> One of the ways the user can modify the configuration is by opening the online editor (PrimeNG has one):
|
|
|
|
|
|
Editing JSON is a hard and non-intuitive task for humans. We should develop a dedicated tool to edit the Kea configuration to avoid common mistakes (such as missing quotes or brackets). We can add a possibility to upload the JSON file as an alternative.
|
|
|
|
|
|
-----
|
|
|
|
|
|
> Problem 3: Reverting changes.
|
|
|
|
|
|
What should happen if the user reverts the changes? Should we remove the newer revisions or allow to re-revert them?
|
|
|
|
|
|
-----
|
|
|
|
|
|
> 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.
|
|
|
|
|
|
I think that it should be done in this way.
|
|
|
Probably we shouldn't introduce the workarounds for the hooks. Additionally, the hooks are the most reliable way to modify the Kea as they share the codebase with it.
|
|
|
|
|
|
|