Design configuration management
Up until 1.0, Stork was a dashboard - monitoring and displaying various things, but not changing any configuration of either Kea or BIND.
This ticket is about designing the ability to manage (change) configuration. Here are some aspects to consider:
- the configuration can be pushed with
config-set. Should it be also stored locally with
config-write? (pro: system is more stable, as it doesn't require stork agent to be up and running and re-push after restart, con: how to handle read-only systems? how to know where the config is supposed to be written? it depends on the startup scripts which config will be loaded).
- reverting changes
- audit trail (who made the changes and when, what kind of changes, which servers were affected)
- scheduling changes (this may be a future mechanism, but the solution should be extensible enough for its future implementation). The good usecase here prepare complex changes in advance and then deploy them at convenient time.
- hook dependence - some mechanisms will work only if the premium hooks are in place (e.g. subnet_cmds, host_cmds)
- extensibility - this is probably an entirely separate topic of how to do optional components (hooks in Stork)