... | ... | @@ -2,7 +2,7 @@ The following page describes several ideas that may be interesting for people co |
|
|
|
|
|
# Feature wish list
|
|
|
|
|
|
## DHCP Degradation Canary
|
|
|
## 1. DHCP Degradation Canary
|
|
|
|
|
|
Stork is able to monitor Kea instances. However, admins want some additional assurance that the server is able to provide a DHCP service. Note that the server is up and alive doesn't imply that it is always able to provide service (think about cases like running out of disk space => memfile will not be able to store leases, the DB credentials problem => DB connection works but is unable to insert leases, firewall problems dropping responses, a bug causing Kea to stuck in an infinite loop or drop responses, various types of misconfiguration, etc). Therefore a mechanism is needed that will act as a DHCP client and actually get a lease (and then release it quickly to not consume resources). The basic approach would be to conduct this action manually, by clicking a button on Stork UI. The improved version would be to offer an ability to conduct such a check periodically. The difficulties are listed below.
|
|
|
|
... | ... | @@ -15,15 +15,15 @@ Stork is able to monitor Kea instances. However, admins want some additional ass |
|
|
|
|
|
Related requirements: https://gitlab.isc.org/isc-projects/stork/-/issues/158
|
|
|
|
|
|
## Display Kea config (JSON)
|
|
|
## 2. Display Kea config (JSON)
|
|
|
As of March 2021, Stork can show specific elements (networks, subnets, reservations), but lacks the ability to show the whole Kea configuration. We would like to get the ability to display the whole configuration assigned to the specific Kea daemon (DHCP server, Control Agent etc). This feature can be implemented incrementally, starting from the easiest to more sophisticated.
|
|
|
1. In the first step, a configuration should be presented in a JSON format with the possibility to show and hide certain nodes.
|
|
|
1. In the second step, some of the elements should be made clickable, and clicking on them would direct the user to the specific view, e.g. shared network view, subnet view etc.
|
|
|
1. Finally, in the third step, the old configurations should be tracked in the Stork database, and it should be possible to view the selected configuration. It must be possible to generate a diff view between any two configurations by selecting them to compare and clicking a compare button. The diff may look the same as a diff between two JSON files in a version control system.
|
|
|
2. In the second step, some of the elements should be made clickable, and clicking on them would direct the user to the specific view, e.g. shared network view, subnet view etc.
|
|
|
3. Finally, in the third step, the old configurations should be tracked in the Stork database, and it should be possible to view the selected configuration. It must be possible to generate a diff view between any two configurations by selecting them to compare and clicking a compare button. The diff may look the same as a diff between two JSON files in a version control system.
|
|
|
|
|
|
Related requirement: https://gitlab.isc.org/isc-projects/stork/-/issues/43
|
|
|
|
|
|
Configurations tracking may sound a bit complicated, but Stork already stores the current configuration in the database as JSONB. We also have a mechanism to detect configuration changes. A new table needs to be added to store old configurations with appropriate metadata and a trigger in the database to move the current configuration to this new table.
|
|
|
Configuration tracking may sound a bit complicated, but Stork already stores the current configuration in the database as JSONB. We also have a mechanism to detect configuration changes. A new table needs to be added to store old configurations with appropriate metadata and a trigger in the database to move the current configuration to this new table.
|
|
|
|
|
|
## Host Reservation details
|
|
|
|
... | ... | |