... | ... | @@ -25,7 +25,7 @@ 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.
|
|
|
|
|
|
## Host Reservation details
|
|
|
## 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:
|
|
|
|
... | ... | @@ -47,12 +47,12 @@ Leases data change dynamically, and we currently have no systematic way of gathe |
|
|
|
|
|
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 to discuss the matter.
|
|
|
|
|
|
## User management - Read-only user
|
|
|
## 4. User management - Read-only user
|
|
|
|
|
|
As of March 2021, Stork has only two user 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.
|
|
|
|
|
|
Related requirement: https://gitlab.isc.org/isc-projects/stork/-/issues/157
|
|
|
|
|
|
## Address allocation details
|
|
|
## 5. Address allocation details
|
|
|
|
|
|
As of March 2021, 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. See [lease tracking design](https://gitlab.isc.org/isc-projects/stork/-/wikis/Leases-Tracking). |