< Networking | Ideas
For the purposess of design and redesign of configuration services that affect various aspects of network-related configuration, I (User:Pavlix) decided to write down a reference architecture that we could later adhere to. I hope other people to step in and improve the description as well as the architecture itself.
A reference architecture for configuration services affecting kernel and long-running daemons
Let's start with the goals. That's the most important part of the whole thing, and also the first thing to be disputed and, if necessary, corrected.
Goals of a configuration service
- Push configuration to kernel and/or long-running services
- Pull existing configuration from kernel and/or long-running services (e.g. after restart)
- Optionally start/stop/reconfigure helper services
- Report the configuration and notify about configuration changes
- Retrieve configuration from disk and (optionally) store configuration to disk
This was just a basic checklist. The goals may have to be tweaked for a particular purpose.
Configuration library and object model
There are many approches to configuration services but I'm going to describe a library-centric one which is different from many services that we are using now. The basic idea behind the architecture I'm proposing is to have a library that defines and exposes the configuration object tree. This library then communicates with backends that handle communication with the kernel and long-running daemons as well as with the filesystem, etc.
Therefore I feel obliged to provide the reasons why a library should be the center of the whole thing:
- A single library API can be used by applications that want to access the configuration directly as well as by various bindings and tools.
- If the configuration daemon is present, it uses the library API to access the operating system backends and the library API can be used to access the daemon.
- In many situations a configuration daemon is not needed and then the tools and application use the same library API to talk to the operating system as it would do to talk to the daemon.