... | ... | @@ -2,29 +2,29 @@ |
|
|
|
|
|
Welcome to Kea 1.9.9, the tenth monthly release of the 1.9 development branch. As with any other development release, use this with caution: development releases are not recommended for production use.
|
|
|
|
|
|
As we are getting closer to upcoming 2.0.0 release, the new features are fewer and smaller. Instead, there are more bug fixes, documentation and small improvements that are expected from a stable software. The most notable changes introduced in this version are:
|
|
|
As the 2.0.0 release approaches, we are adding fewer and less significant new features. Instead, there are more bug fixes, documentation edits, and small improvements that are expected from stable software. The most notable changes introduced in this version are:
|
|
|
|
|
|
1. **New GSS-TSIG premium hook** - There is a work in progress to implement GSS-TSIG extension, which integrates DNS updates with Windows Active Directory. This subscriber-only hook is not functional yet, however it may be used as a technology preview for customers who would like to take an early look. It provides support for two Kerberos implementations: MIT and Heimdal. It is a first hook that can be loaded by D2 (dhcp-ddns) daemon [#1884,#1909, #1880].
|
|
|
1. **New GSS-TSIG premium hook** - There is work in progress to implement a GSS-TSIG extension, to integrate DNS updates with Windows Active Directory. This subscriber-only hook is not functional yet; however, it is available as a technology preview for customers who would like to take an early look. It provides support for two Kerberos implementations: MIT and Heimdal. It is the first hook that can be loaded by the D2 (dhcp-ddns) daemon [#1884, #1909, #1880].
|
|
|
|
|
|
2. **dhcp-server-identifier in client class** - Kea now allows definition of `dhcp-server-identifier` in a class scope. This capability is typically not needed, but may be used by advanced users to segregate their traffic to based on device types [#1836].
|
|
|
2. **dhcp-server-identifier in client class** - Kea now allows the definition of a `dhcp-server-identifier` in a class scope. This capability is typically not needed, but may be used by advanced users to segregate their traffic based on device types [#1836].
|
|
|
|
|
|
3. **Cassandra is now deprecated** - See the incompatible changes below [#1892].
|
|
|
3. **Cassandra is now deprecated** - See the Incompatible Changes section below [#1892].
|
|
|
|
|
|
4. **Improvements** - Kea now prints much more detailed information about the subnet, when allocation engine fails to allocate an address. This extra information will make it easier to investigate the problem [#1915]. A new debuglevel 15 has been introduced. Log messages are now more consistent regardless of the reason of a drop [#1916]. The suboption 1 is treated as PRL/ORO only for DOCSIS packets [#1894]. The documentation now builds with older Sphinx versions [#1937]. Kea-admin tool now produce more useful error messages [#1653]. The run script hook now has more parameters [#1840]. The run script hook now handles the signals better [#1720].
|
|
|
4. **Improvements** - Kea now prints much more detailed information about the subnet, when the allocation engine fails to allocate an address. This extra information makes it easier to investigate any problems [#1915]. A new debug level 15 has been introduced; log messages are now more consistent regardless of the reason for a drop [#1916]. Suboption 1 is treated as PRL/ORO only for DOCSIS packets [#1894]. The documentation now builds with older Sphinx versions [#1937]. The Kea-admin tool now produces more useful error messages [#1653]. The run script hook now has more parameters [#1840]. The run script hook now handles signals better [#1720].
|
|
|
|
|
|
5. **Bug fixes** - The IOService is now destroyed in a safer manner during shutdown, preventing rare crashes during shutdown [#1948] The HA+MT client now correctly logs the number of threads [#1902]. A race condition in database reconnect code has been eliminated [#1861]. One case where run script hook could have left zombie processes in the background has been fixed [#1878]. A problem where PSID field in the MAP option could have been set incorrectly under certain conditions has been fixed [#1858]. Many previously uninitialized members are now initialized properly [#1845, #1906]. Addressed several thread sanitizer warnings in the HTTP client tests [#1817]. Several compilation warnings have been fixed [#1899].
|
|
|
5. **Bug fixes** - The IOService is now destroyed in a safer manner during shutdown, preventing rare crashes during shutdown [#1948]. The HA+MT client now correctly logs the number of threads [#1902]. A race condition in the database reconnect code has been eliminated [#1861]. One case where the run script hook could have left zombie processes in the background has been fixed [#1878]. A problem where the PSID field in the MAP option could be set incorrectly under certain conditions has been fixed [#1858]. Many previously uninitialized members are now initialized properly [#1845, #1906]. Several thread sanitizer warnings have been addressed in the HTTP client tests [#1817]. Several compilation warnings have been fixed [#1899].
|
|
|
|
|
|
6. **Documentation** The ARM has gotten a new appendix dedicated to Kea configuration files. All possible configuration parameters in DHCPv4, DHCPv6, D2, CA and NETCONF daemons are presented as BNF notation and are generated automatically, which should ensure that this list will be kept up to date [#504, #745]. Many corrections have been done to Kea ARM [#1917]. The outdated note about HA+MT being in active development has been removed [#1901]. Fixed examples in forensic logging v4 section in the ARM [#1862]. Removed duplicate forensic logging documentation sections [#1864].
|
|
|
6. **Documentation** The ARM has a new appendix dedicated to Kea configuration files. All possible configuration parameters in DHCPv4, DHCPv6, D2, CA, and NETCONF daemons are presented as BNF notation and are generated automatically, which should ensure that this list is kept up to date [#504, #745]. Many corrections have been made to the Kea ARM [#1917]. The outdated note about HA+MT being in active development has been removed [#1901]. Examples in the forensic logging v4 section in the ARM have been fixed [#1862]. Duplicate forensic logging documentation sections have been removed [#1864].
|
|
|
|
|
|
7. **Test improvements** Several test improvements have been made [#1913, #1941] Perfdhcp testing tool is now able to send RELEASE packets in DHCPv4 [#1119]. Hammer, our build tool, now supports FreeBSD 13, Fedora 34, Ubuntu 21.04, and Alpine 3.13 [#1921, #1658]. Fixed mixedSignal unit-test failure on CentOS 7 [#1769].
|
|
|
7. **Test improvements** Several test improvements have been made [#1913, #1941]. The perfdhcp testing tool is now able to send RELEASE packets in DHCPv4 [#1119]. Hammer, our build tool, now supports FreeBSD 13, Fedora 34, Ubuntu 21.04, and Alpine 3.13 [#1921, #1658]. A mixedSignal unit-test failure on CentOS 7 has been fixed [#1769].
|
|
|
|
|
|
8. **Community** The Kea project would like to make it easier for people to participate. For that reason, we picked some tickets as easy for newcomers. Look for `beginner` label in our gitlab project. Also, we added Linux Foundation's Developer's Certificate of Origin. It's a very short statement that the contributors confirm they're allowed to contribute the code [#1895].
|
|
|
8. **Community** The Kea project would like to make it easier for people to participate in the software's development, so we chose some tickets that should be easy for newcomers to work on. Look for the `beginner` label in our GitLab project. Also, we added Linux Foundation's Developer's Certificate of Origin. It's a very short statement by which contributors confirm that they are allowed to contribute code [#1895].
|
|
|
|
|
|
9. **Config Backend for Postgres**. We are working on Configuration Backend implementation that will use PostgreSQL, rather than MySQL. It is unclear if this feature will be complete in time for 2.0.0 or not. As such, the partial changes made so far are not part of the release. However, since this work was done during the 1.9.9 timeframe, it's mentioned here. People interested may take a look at the `feature-pg-cb` branch here: https://gitlab.isc.org/isc-projects/kea/-/tree/feature-pg-cb. So far the only feature is the 7.0 schema, which is available in `src/share/database/scripts/pgsql` directory.
|
|
|
9. **Config Backend for Postgres**. We are working on a Configuration Backend implementation that will use PostgreSQL rather than MySQL. It is unclear whether this feature will be complete in time for 2.0.0; as such, the partial changes made so far are not part of this release. However, since this work was done during the 1.9.9 timeframe, it is mentioned here. Anyone who is interested may take a look at the `feature-pg-cb` branch here: https://gitlab.isc.org/isc-projects/kea/-/tree/feature-pg-cb. So far the only feature is the 7.0 schema, which is available in the `src/share/database/scripts/pgsql` directory.
|
|
|
|
|
|
## Incompatible Changes
|
|
|
|
|
|
1. **Deprecate Cassandra** - The Cassandra support is now deprecated. If you use it - don't panic. The only technical change for now is that Kea will print a warning about the feature being deprecated, but will otherwise function as before. Cassandra code will remain intact in the remainder of the development 1.9.x and upcoming stable 2.0.x series. We are looking at removing it some time during the development 2.1.x series. The 2.2.x is foreseen to be the first stable branch with the Cassandra support removed. This effectively means that users have well over a year to think about their migration strategy. There is a new Section `3.8 Deprecated Features` in the ARM that discusses the technical and business reasons why we decided to deprecate Cassandra. Briefly, Cassandra's very different data model compared to other backends, namely MySQL and PostgreSQL, made it an ongoing maintenance and development pain, some concepts simply couldn't be implemented as it was not the right tool to solve some of the DHCP problems. Also, there are many warning signs that Cassandra project is having difficulties: packages for popular systems are not available, the C++ wrapper had a note about being in maintenance only for a while, the release versions of Cassandra require obsolete python 2 (with the python 3 support being available in unreleased alpha versions of Cassandra), they don't work with Java 11 (and require outdated Java 8) and more. It was also by far the least popular backend.
|
|
|
1. **Deprecate Cassandra** - Cassandra support is now deprecated. If you use it - don't panic. The only technical change for now is that Kea prints a warning about the feature being deprecated, but it otherwise functions as before. Cassandra code will remain intact in the remainder of the development 1.9.x and upcoming stable 2.0.x series. We are looking at removing it sometime during the development 2.1.x series. Version 2.2.x is foreseen to be the first stable branch with Cassandra support removed. This effectively means that users have well over a year to think about their migration strategy. There is a new Section `3.8 Deprecated Features` in the ARM that discusses the technical and business reasons why we decided to deprecate Cassandra. Briefly, Cassandra's very different data model compared to other backends, namely MySQL and PostgreSQL, made it an ongoing maintenance and development challenge; some concepts simply could not be implemented as it was not the right tool to solve some DHCP problems. Also, there are many warning signs that the Cassandra project is having difficulties: packages for popular systems are not available, the C++ wrapper has a note about being in maintenance only for a while, the release versions of Cassandra require obsolete Python 2 (with Python 3 support being available in unreleased alpha versions of Cassandra), they don't work with Java 11 (and require outdated Java 8), and more. It was also by far the least popular backend.
|
|
|
|
|
|
## Known Issues
|
|
|
|
... | ... | @@ -38,7 +38,7 @@ https://gitlab.isc.org/isc-projects/kea/issues?label_name%5B%5D=bug |
|
|
|
|
|
## Release Model
|
|
|
|
|
|
The Kea project has a significant production deployment base with users who are looking for stability, rather than a constant stream of new "bleeding-edge" features. At the same time, we want to continue developing the software and add some new powerful, but difficult-to-implement, features. To meet both of these requirements we have both Stable and Development branches.
|
|
|
The Kea project has a significant production deployment base with users who are looking for stability, rather than a constant stream of new "bleeding-edge" features. At the same time, we want to continue developing the software and add some new powerful, but difficult-to-implement, features. To meet these requirements we have both Stable and Development branches.
|
|
|
|
|
|
Stable releases are what you would expect: stable, released infrequently, without new features or significant changes, very well-tested. These can be identified by an even-numbered minor version number. The current stable release is 1.8.2. The older stable version of 1.6.3 is also available. If we discover important bugs that require fixing, we may release additional maintenance versions on the 1.8 branch, but that will be determined on a case-by-case basis. The next major stable version will be 2.0.0.
|
|
|
|
... | ... | @@ -54,7 +54,7 @@ https://kb.isc.org/docs/aa-00896 |
|
|
|
|
|
## Kea Overview
|
|
|
|
|
|
Kea is a DHCP implementation developed by Internet Systems Consortium that features fully functional DHCPv4 and DHCPv6 servers, a dynamic DNS update daemon, a Control Agent (CA) that provides a REST API to control the DHCP and DNS update servers, an example shell client to connect to the CA, a daemon that is able to retrieve YANG configuration and updates from Sysrepo, and a DHCP performance-measurement tool. Both DHCP servers support server discovery, address assignment, renewal, rebinding, release, decline, information request, DNS updates, client classification, and host reservations. The DHCPv6 server also supports prefix delegation. Lease information is stored in a CSV file by default; it can optionally be stored in a MySQL, PostgreSQL, or Cassandra database instead. Host reservations can be stored in a configuration file, or in a MySQL, PostgreSQL, or Cassandra database. They can also be retrieved from a RADIUS server, although this functionality is somewhat limited. Kea DHCPv4 and DHCPv6 daemons provide support for YANG models, which are stored in a Sysrepo datastore and can be configured via the NETCONF protocol.
|
|
|
Kea is a DHCP implementation developed by Internet Systems Consortium that features fully functional DHCPv4 and DHCPv6 servers, a dynamic DNS update daemon, a Control Agent (CA) that provides a REST API to control the DHCP and DNS update servers, an example shell client to connect to the CA, a daemon that is able to retrieve YANG configuration and updates from Sysrepo, and a DHCP performance-measurement tool. Both DHCP servers support server discovery, address assignment, renewal, rebinding, release, decline, information request, DNS updates, client classification, and host reservations. The DHCPv6 server also supports prefix delegation. Lease information is stored in a CSV file by default; it can optionally be stored in a MySQL, PostgreSQL, or Cassandra (now deprecated) database instead. Host reservations can be stored in a configuration file, or in a MySQL, PostgreSQL, or Cassandra (now deprecated) database. They can also be retrieved from a RADIUS server, although this functionality is somewhat limited. Kea DHCPv4 and DHCPv6 daemons provide support for YANG models, which are stored in a Sysrepo datastore and can be configured via the NETCONF protocol.
|
|
|
|
|
|
This text references issue numbers. For more details, visit the Kea GitLab page at:
|
|
|
|
... | ... | |