... | ... | @@ -16,15 +16,29 @@ Stork is able to monitor Kea instances. However, admins want some additional ass |
|
|
Related requirements: https://gitlab.isc.org/isc-projects/stork/-/issues/158
|
|
|
|
|
|
## 2. Display Kea config (JSON)
|
|
|
|
|
|
[Stork](https://gitlab.isc.org/isc-projects/stork) is a UI/dashboard tool for monitoring [Kea](https://gitlab.isc.org/isc-projects/kea) DHCP server. Kea uses extended JSON (JSON with javascript comments) to store its configuration. An assortment of examples can be found in `doc/examples/kea4` and doc/examples/kea6` in the Kea sources. The Stork server already has the capability to retrieve that information using the existing API (it instructs stork-agent to call `config-get` command on Kea). The retrieved information is then stored on the stork-server in a PostgreSQL database.
|
|
|
|
|
|
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. There's some degree of flexibility here. One potential way to visualize would be a tree with expandable/hidable sub-trees.
|
|
|
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.
|
|
|
|
|
|
* **Phase 1**. In the first step, a configuration should be presented in a JSON format with the possibility to show and hide certain nodes. There's some degree of flexibility here. One potential way to visualize would be a tree with expandable/hidable sub-trees.
|
|
|
* **Phase 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.
|
|
|
* **Phase 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
|
|
|
|
|
|
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.
|
|
|
|
|
|
Here's a high level sketch of tasks required to complete phase 1:
|
|
|
|
|
|
- Evaluate if stork-server code (written in go) provides an API to make the configuration available. The Kea config information is there and there are API calls (such as `/hosts`, `/overview`, `/shared-networks` and `/subnets`) that return specific fragments of the configuration, but most likely there will be a need to implement new API call that return it as a whole JSON structure.
|
|
|
- Extend the Angular interface to visualize the Kea configuration. The visualization can be simple for now, but it should be extensible, so the more complicated tasks would be possible in the future. See Phase 2 and 3 above. The current Stork interface is implemented using AngularJS 9 (migration to 10 is planned) with extensive used of PrimeNG library.
|
|
|
- The solution should have unit tests (see [Stork ARM Sections 5.6 and 5.7](https://kea.readthedocs.io/projects/Stork/en/v0.15.0/devel.html) )
|
|
|
- The solution should have adequate code comments
|
|
|
- The patch will go through a normal review that applies to all existing Stork developers. The process is [described here](https://gitlab.isc.org/isc-projects/stork/-/wikis/Processes/gitlab-howto).
|
|
|
|
|
|
The phase 1 is expected to take roughly a month to complete. However, Stork is a long term project and ISC values code quality over rapid delivery, so there is some flexibility here.
|
|
|
|
|
|
## 3. Host Reservation details
|
|
|
|
|
|
Stork is able to show host reservations from Kea, but as of March 2021, its capabilities are basic - only identifier (e.g. MAC or DUID), IP address, delegated prefix, hostname and whether the reservation was retrieved from config or host backend, are shown. The missing pieces are:
|
... | ... | |