... | @@ -54,7 +54,14 @@ Stork must facilitate both described configuration approaches. Consider a case w |
... | @@ -54,7 +54,14 @@ Stork must facilitate both described configuration approaches. Consider a case w |
|
The Stork data model was designed with these different configuration perspectives in mind. In the database, the `subnet` table comprises the common subnet information, such as `prefix` and dynamic pools. Multiple DHCP servers can be associated with a subnet via the `local_subnet` table. It comprises DHCP server-specific information about subnets and creates a many-to-one relationship with them.
|
|
The Stork data model was designed with these different configuration perspectives in mind. In the database, the `subnet` table comprises the common subnet information, such as `prefix` and dynamic pools. Multiple DHCP servers can be associated with a subnet via the `local_subnet` table. It comprises DHCP server-specific information about subnets and creates a many-to-one relationship with them.
|
|
|
|
|
|
## Runtime and Source Configuration
|
|
## Runtime and Source Configuration
|
|
TBD
|
|
|
|
|
|
It is easiest to explain the difference between the runtime and source configurations on the Kea example. Every Kea instance must have a configuration file. It may comprise the entire configuration, or the configuration can be dispersed. Some configuration parts can be stored in a database (config backend). It is also common to keep host reservations in the database.
|
|
|
|
|
|
|
|
Stork gathers a DHCP configuration by issuing a `config-get` command that returns a runtime configuration of the Kea daemon. It is the configuration that the daemon uses to operate, and it combines the configuration parts from all sources, typically a configuration file and backend. If the configuration from the file and the backend overlap, the conflicting parts from the backend take precedence.
|
|
|
|
|
|
|
|
The partial configuration stored in the configuration file is herein called a source configuration. Similarly, the part stored in the config backend is also called a source configuration. A specific combination of the source configurations created by the Kea server yields a runtime configuration. In some cases, a runtime configuration can be equivalent to the source configuration.
|
|
|
|
|
|
|
|
At the time of writing this design, the Stork server has no access to any of the Kea source configurations. The `stork-agent` accesses the Kea Control Agent's source configuration (configuration file) to detect communication endpoints. It doesn't access any of the source configurations otherwise. In order to implement configuration management, we will need to allow access to the source configurations. Stork must not modify runtime configuration because such modifications are not permanent and may conflict with the source configurations (e.g., with the config backend).
|
|
|
|
|
|
## Modifying Source Configuration
|
|
## Modifying Source Configuration
|
|
TBD
|
|
TBD
|
... | | ... | |