... | ... | @@ -2,15 +2,15 @@ |
|
|
|
|
|
Welcome to the Stork 0.16.0 release, which now returned to the monthly releases cycle. The changes introduced in this version are:
|
|
|
|
|
|
* **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.
|
|
|
* **Leases information**: In this release, the major effort was focused on handling lease information. 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. Also, Stork gained the ability to show information about Kea backends. While the feature is generic and allows showing the storage location of leases, host, and config backends, our driving motivation was the ability to show lease backend details #299.
|
|
|
|
|
|
* **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.
|
|
|
* **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 since 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 from Kea in a continuous manner. The design is available here: https://gitlab.isc.org/isc-projects/stork/-/wikis/Leases-Tracking We'd appreciate comments and feedback. This design has been completed in Kea ticket #1230.
|
|
|
|
|
|
* **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.
|
|
|
* **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 in the DHCPv6 protocol and instead, the status is conveyed with `status-code` option. Another notable difference is that it's infeasible to show pool utilization as percentage. No matter how many devices you have in your IPv6 network, the number is insignificantly small against quintillions of addresses available that you have even in the smallest /64 networks. We're eager to get your feedback and suggestions how to expand this and other Stork dashboards #176, #469.
|
|
|
|
|
|
* **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.
|
|
|
* **TLS improvements**: We followed up on the TLS work done in the previous release, improved several aspects related to testing #487, and made the agent actually obey the host information where to listen for incoming server connections as specified by the user #504.
|
|
|
|
|
|
* **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.
|
|
|
* **Bugfixes and smaller improvements**: With the major task of adding TLS mostly complete, we could get back to fixing smaller bugs and make the 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 a 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.
|
|
|
|
... | ... | |