... | ... | @@ -8,13 +8,13 @@ This design mostly focuses on extending Stork to facilitate Kea configuration ma |
|
|
|
|
|
Even only considering Kea management, Kea servers have a modular nature with hooks libraries and can be connected with external programs, such as databases or Radius. We currently do not require Stork to monitor or manage the databases or any other third party application, but it should be considered a likely future requirement.
|
|
|
|
|
|
Stork's interesting future use case is to automatically create and configure a new Kea instance. Suppose the Kea instance uses a database as a lease, host, or configuration repository. In that case, Stork will become responsible for creating a database schema and applying any other required settings in the database server. It implies direct interactions between Stork and the database. In that scenario, the database server becomes an application managed by Stork, just like Kea or Bind9. In summary, Stork's interaction with the databases could include but not be limited to:
|
|
|
Stork's interesting future use case is to automatically create and configure a new Kea instance. Suppose the Kea instance uses a database as a lease, host, or configuration repository. In that case, Stork will become responsible for creating a database schema and applying required settings in the database server. It implies direct interactions between Stork and the database. In that scenario, the database server becomes an application managed by Stork, similar to Kea or Bind9. Stork's interaction with the databases could include but not be limited to:
|
|
|
|
|
|
- setting up new databases in the database servers,
|
|
|
- running database health checks,
|
|
|
- database content dumps on request (for troubleshooting and support purposes)
|
|
|
- creating database content dumps on request (for troubleshooting and support purposes)
|
|
|
|
|
|
Keeping in mind that Stork may evolve into a system for controlling more application types than Kea, we should generalize as many aspects of the configuration management as possible. Specifically, a fundamental question is "what tools and communication methods are common to manage different applications?". We will focus on this topic further in the further sections.
|
|
|
Keeping in mind that Stork may evolve into a system for controlling more application types than Kea, we should generalize as many aspects of the configuration management as possible. Specifically, a fundamental question is "what tools and communication methods are common to manage different applications?". We will focus on this topic in the further sections.
|
|
|
|
|
|
## Interactions with Applications
|
|
|
TBD
|
... | ... | |