|
|
The following page describes several ideas that may be interesting for people considering or joining the project. This list is not ordered by any particular order.
|
|
|
|
|
|
# Currently available ideas
|
|
|
|
|
|
* **DHCP Degradation Canary** - Stork is able to monitor Kea instances. However, admins want some additional assurance that the server is able to provide 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 here are:
|
|
|
|
|
|
- figure out who will send it - the server or agent. Both approaches have pros and cons.
|
|
|
- figure out how to conduct DHCP exchange. Getting DHCP implementation in go is one option. Using an external tool, such as perfdhcp, is another.
|
|
|
- figure out how to store the responses and get as much info from the exchange (maybe measure latency?)
|
|
|
- if this is sent by an agent, an API is needed for the server to use it
|
|
|
- if this is sent by a server, the scalability needs to be considered
|
|
|
|
|
|
|
|
|
* **Display Kea config (JSON)** - As of March 2020, 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 show the whole configuration. The most basic approach would be to simply show it as JSON. A slightly more advanced view would allow clicking on specific elements (such as network), to be taken to dedicated views, e.g. for subnets there could be a button "show reservations in this subnet", which would lead to existing functionality in Stork). An advanced feature would be to show older Kea configurations and show differences. Stork already stores older configurations, pools Kea configuration periodically and is able to detect changes.
|
|
|
|
|
|
* **Host Reservation details** - Stork is able to show host reservations from Kea, but as of March 2020, its capabilities are basic - only identifier (e.g. MAC or DUID), IP address, hostname and whether the reservation was retrieved from config or host backend, is shown. The missing features are: fixed fields (e.g. bootfile, sname), options, client classes, multiple prefixes in v6. An advanced feature would be to show whether the reservation is currently in use or not (check if there's a lease).
|
|
|
|
|
|
## Potential future ideas
|
|
|
|
|
|
The following areas of interest are currently blocked for various technical and business reasons. If you are interested, please reach out to the Stork team and we may figure something out.
|
|
|
|
|
|
* **User management** - As of March 2020, Stork has only two roles: super-admin (can do everything) and admin (can do everything, except managing other users). We need more fine grained access control. The most basic addition would be a read-only user. This would be used by a junior admin, who can only observe the system, but is not permitted to make any changes. In the future, the role system will become more sophisticated, so the solution must be extensible. In particular, the following use cases will need to be possible: a role to manage a single server, a role to manage certain subnet (including situations where it is handled by a pair of HA servers). This is currently blocked, because the Stork team needs to write down requirements and our early attempt indicates it's more complex than it looks at the first glance.
|
|
|
|
|
|
* **Showing pool status** - As of March 2020, we have the ability to show statistics for networks and subnets. We can say that 30 of 250 addresses are used. The statistics are good first approximation, but they have several flaws. First, there were bugs in statistics that caused them to not truly reflect the pool state, in particular in cases where several Kea instances are sharing the same DB. Second, getting an overview of the pool utilization is often not enough and admins want to have more detailed insight. The major difficulty here is to come up with an efficient way to keep this information roughly up to date. The current mechanisms available in Kea (e.g. lease4-get-all) are insufficient and wouldn't scale for deployments that count devices in millions. There's a plan to implement [incremental lease updates](https://gitlab.isc.org/isc-projects/kea/-/issues/1230), so Stork would retrieve all leases just once (that's acceptable) and then only get the lease updates periodically. This is currently blocked until such a mechanism is implemented in Kea. |