declarative config - Lua API extension
I would like to open a discussion as a follow up after #536 (closed). The problem remains and this proposal attempts to fix it differently.
Current configuration is practically a Lua program, which is a nightmare for multiple reasons:
- non-programmers have hard time understanding what is going on
- Lua language makes it hard to detect mistakes in the config
- run-time reconfiguration requires doing each change N times for N processes
- currently it exposes low-level stuff and it prone to crashes on invalid use (#182)
We could extend kresd API with the following function:
--- Sets the resolver to supplied state regardless of what was configured --- before. Options that aren't specified in the argument are set to their --- default value --- --- @param cfg Table corresponding to the existing YANG model function configure(cfg)
And optionally with this:
--- Returns a table corresponding to the existing YANG model with the current --- configuration. function dump_configuration()
- extends existing API, this change will not break any existing setup
- works with simple data formats so it is quite feasible to implement the whole functionality in pure Lua
- Updates of policies or other large data might be performed by the existing API, side-stepping the new configuration functions, alleviating performance issues with the declarative API.
- relatively simple to implement
- new file configuration format might be easily added later on allowing direct declarative configuration
- implements foundation for dynamically reloadable configuration - adding it on top of the declarative configuration (in the previous bullet point) would be quite straightforward
- At least some validation of the data format must be present in every kresd instance. By exposing these functions publicly, there is no way to go around that. An option might be to make something very similar but private. Then a centralized configuration tool (see bellow) could do the validation eliminating the need for validation by every instance.
To be considered
- Is it really a good idea to use Lua tables as the configuration format? Lua is not backward compatible between releases which might lead to potential problems. Using JSON instead might be more future proof and it might integrate better with existing tools.
- Do we really want to stick to the existing Lua API? Wouldn't it be better to implement something completely new allowing us to ditch the existing API at some point in the future?
Centralized management of multiple instances
To enable centralized management of multiple instances, a separate tool can be developed utilizing both new functions described above. It could provide any type of external API (NETCONF, REST API, sysrepo, different centralized configuration file...) and bridge it to our two new functions, calling them for all resolver instances as necessary. We could even implement this in a form of a library for commanding all kresd instances on the system at once, leaving the external API implementation up to interested parties in their specific technologies.
Basics of this were already written by @amrazek in the form of the