... | ... | @@ -4,8 +4,15 @@ Welcome to the Stork 0.16.0 release. This is a development release of the Stork |
|
|
|
|
|
The changes introduced in this version are:
|
|
|
|
|
|
* **Topic**: Descr.
|
|
|
* **Leases information**: In this release, the major effort was focused on handling lease information. Stork gained the ability to show information about Kea backends. While the feature is generic and allows showing the location of leases, host, and config backends, our driving motivation was the ability to show lease backend details #299. Stork is now able to do a lease inspection. Leases can be searched by IP address, by MAC address, by DUID (v6 only), or by client-id. The lookup shows results from all servers, if available. This is particularly useful to inspect leases on a HA pair, which should match between partners in normal operation #509.
|
|
|
|
|
|
* **Design for incremental lease retrieval**: As of this release, Stork is able to look up single leases, using `leaseX-get` API calls that been provided by Kea 1.3.0. This API works well for single leases but does not scale for massive updates for all leases, especially for larger deployments. For this purpose, we came up with a design that would allow Stork to retrieve lease updates in a continuous manner. This design has been completed in Kea ticket #1230.
|
|
|
|
|
|
* **TLS improvements**: We followed up on the TLS work done in the previous release, improved several aspects related to testing #487 and the agent now obeys the host information where to listen for incoming server connections #504.
|
|
|
|
|
|
* **DHCPv6 dashboard for Grafana**: Stork supports DHCPv6 from its very early days, including exporting statistics to Prometheus. However, until now, there was no DHCPv6 dashboard for Grafana that could take advantage of that. There is now. We tried to make it look as similar to DHCPv4 as possible, but there are some differences. There is no concept of `ACK/NAK` packets and instead, the status is conveyed with `status-code` option. Another notable difference is that it's infeasible to show pool utilization as is. No matter how many devices you have in your IPv6 network, the number is insignificantly small against quintillions that you have even in the smallest /64 networks. The reporting will be improved in the future, but it would require some changes in the Kea code first #176, #469.
|
|
|
|
|
|
* **Bugfixes and smaller improvements**: With the major task of adding TLS mostly complete, we could get back to fixing smaller bugs and make quality of lives improvements again. The demo is now more resilient with some fixed in the connectivity between the Stork server and `agent-kea` #517, the internal IDs used by our front-end code now follow naming convention that is very helpful for our QA dept, especially for developing better automated tests #455, fixed broken Prometheus exporter on one of the demo containers #494.
|
|
|
|
|
|
Please see this link for known issues: https://gitlab.isc.org/isc-projects/stork/-/wikis/Known-issues.
|
|
|
|
... | ... | |