... | @@ -4,17 +4,17 @@ Welcome to Kea 1.9.5, the fifth monthly release of the 1.9 development branch. A |
... | @@ -4,17 +4,17 @@ Welcome to Kea 1.9.5, the fifth monthly release of the 1.9 development branch. A |
|
|
|
|
|
This release adds new features, improves existing features, clarifies documentation and fixes a few bugs. The most notable changes introduced in this version are:
|
|
This release adds new features, improves existing features, clarifies documentation and fixes a few bugs. The most notable changes introduced in this version are:
|
|
|
|
|
|
**New script hook.** Due to popular demand a new hook that calls arbitrary external script has been added. The most common use case is expected to be routing and firewall update for provisioned devices, but many other scenarios may benefit from this. The script is called asynchronous, i.e. Kea starts the script, doesn't wait for its completion, and continues onwards with processing the packet. This approach greatly decreases performance impact. This hook has been only lightly tested. Use with caution and please do share your experience #899.
|
|
**New script hook.** Due to popular demand a new hook that calls an arbitrary external script has been added. These scripts may initiate an external process, such as, for example, updating routing and firewall rules for provisioned devices. The script is called asynchronously, i.e. Kea starts the script, doesn't wait for its completion, and continues with processing the packet. This approach greatly decreases performance impact. This hook has been only lightly tested. Use with caution and please do share your experience #899.
|
|
|
|
|
|
**Setting lease time for client classes.** Earlier Kea versions allowed to set different lease lifetimes depending on where the device was located in your network (using the global, network, or subnet levels). However, it was impossible to change the lifetime based on device type. This missing capability is now implemented for IPv4, with IPv6 support coming up soon #1635.
|
|
**Setting lease time for client classes.** Earlier Kea versions allowed setting different lease lifetimes depending on where the device was located in the network (using the global, network, or subnet levels). However, it was impossible to set the lifetime based on device type. This missing capability is now implemented for IPv4, with IPv6 support coming up soon #1635.
|
|
|
|
|
|
**TLS support work in progress.** The Kea team continues its work on TLS implementation in Kea. The ultimate goal is for CA to be able to accept https connections. While the TLS solution is not usable yet, the work is definitely picking up the pace with several important milestones being completed. There are now several new parameters available in Control Agent (CA) configuration: `trust-anchor`, `cert-file`, `key-file` and `cert-required`. The parameters can be configured, but they are not used yet. A new config example `doc/examples/agent/https.json` has been added with some commentary #1662. Another under the hook change updated the asiolink library to be able to handle the new TLS socket type. This is not a user-visible change #1644.
|
|
**TLS support work in progress.** The Kea team continues its work on implementing TLS in Kea. The ultimate goal is for the CA to be able to accept HTTPS connections. While the TLS solution is not usable yet, several important milestones have been completed. There are now several new parameters available in the Control Agent (CA) configuration: `trust-anchor`, `cert-file`, `key-file` and `cert-required`. The parameters can be configured, but they are not used yet. A new config example `doc/examples/agent/https.json` has been added with some commentary #1662. Another change updated the asiolink library to be able to handle the new TLS socket type. This is not a user-visible change #1644.
|
|
|
|
|
|
**DB cluster improvements.** Kea never officially supported any DB clustering solutions. Nevertheless, people used clusters with varying results. ISC team began experiments with several clustering solutions: Galera, Percona, NDB, and group replication. While we don't officially any of them yet, we are gaining experience and testing many scenarios right now. Those experiments reached a stage where we are able to set up clusters and run unit and system tests. The first two improvements are related to our MySQL libraries to better run on the Percona cluster. One ticket updated the MySQL schema with the primary key for forensic logging (#1709), while another fixed several problems in unit tests that manifested themselves only on Percona (#1708). Finally, we are getting ready to run performance tests of multiple Kea instances connected to the DB cluster. To do that reliably, we need to export the list of leases assigned by each instance and then correlate them to check for any duplicates. With that in mind, we extended `perfdhcp` tool with the ability to export the list of assigned leases. We hope to make good use of that capability in future tests #1703.
|
|
**DB cluster improvements.** Kea does not officially support any DB clustering solutions. We have heard from users who have used clustering solutions with varying results. The ISC team has begun experimenting with Galera, Percona, NDB, and group replication. We set up clusters and ran unit and system tests and found a few issues to address. The first two improvements make our MySQL libraries run better in a Percona cluster. One ticket updated the MySQL schema with the primary key for forensic logging (#1709), while another fixed several problems in unit tests that manifested themselves only on Percona (#1708). Finally, we are getting ready to run performance tests of multiple Kea instances connected to a DB cluster. To do that reliably, we need to export the list of leases assigned by each instance and then correlate them to check for any duplicates. With that in mind, we extended our `perfdhcp` tool with the ability to export the list of assigned leases. We hope to make good use of that capability in future tests #1703.
|
|
|
|
|
|
**Bug fixes.** Earlier Kea versions could experience a DB access deadlock when processing high request rate with forensic logging hook configured to write log entries to a database and multi-threading was enabled. This release includes a fix for this problem #1711. One user reported that Kea used values defined in client classes in non-deterministic way. The behavior was deterministic, but DHCP options and DHCP fixed fields had followed different logic, giving an illusion of randomness. The code has been updated to provide consistent behavior for options and fixed fields #1672. When dealing with client classification, it is possible to encounter a situation when there are subnets and pools available, but due to the client not meeting the class requirements is unable to use any of them. In such cases, earlier Kea versions printed cryptic error messages, such as `failed to allocate an IPv4 address after 0 attempt(s)`. This was confusing and required deep understanding of the allocation engine internals to understand the reasons behind it. The message was tweaked and there are several additional messages that explain the reasons why the allocation failed and more details are available to easier debug the problems #1701.
|
|
**Bug fixes.** Earlier Kea versions could experience a DB access deadlock when processing a high request rate while the forensic logging hook was configured to write log entries to a database and multi-threading was enabled. This release includes a fix for this problem #1711. One user reported that Kea used values defined in client classes in a non-deterministic way. The code has been updated to provide consistent behavior for options and fixed fields #1672. When dealing with client classification, it is possible to encounter a situation when there are subnets and pools available, but due to the client not meeting the class requirements is unable to use any of them. In such cases, earlier Kea versions printed cryptic error messages, such as `failed to allocate an IPv4 address after 0 attempt(s)`. This was confusing. The message has been tweaked and there are several additional messages that explain the reasons why the allocation failed. More details are available debug the problem #1701.
|
|
|
|
|
|
**MySQL DB upgrade improvements.** Two last development releases had incorrectly versioned database schema. As a result, when upgrading from 1.9.2 or 1.9.3 to 1.9.4 the `kea-admin` tool incorrectly assumed the schema is already updated, when if fact it wasn't. This is now corrected #1698. Upgrading from any earlier Kea versions to 1.9.5 work and work around for ugprading to 1.9.4 is documented in Known issues list. See the link below.
|
|
**MySQL DB upgrade improvements.** Two prior development releases had incorrectly versioned database schema. As a result, when upgrading from 1.9.2 or 1.9.3 to 1.9.4 the `kea-admin` tool incorrectly assumed the schema was already updated, when if fact it wasn't. This is now corrected #1698. Upgrading from any earlier Kea versions to 1.9.5 work and a work around for ugprading to 1.9.4 is documented in the Known issues list. See the link below.
|
|
|
|
|
|
## Incompatible Changes
|
|
## Incompatible Changes
|
|
|
|
|
... | @@ -34,7 +34,7 @@ https://gitlab.isc.org/isc-projects/kea/issues?label_name%5B%5D=bug |
... | @@ -34,7 +34,7 @@ https://gitlab.isc.org/isc-projects/kea/issues?label_name%5B%5D=bug |
|
|
|
|
|
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 both of 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 releases are 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.
|
|
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.
|
|
|
|
|
|
Development releases can be easily identified by an odd minor version number: for example, 1.9.0 is a development release. Subsequent releases on the same minor release branch get numbered with 1.9.1, 1.9.2, and so on.
|
|
Development releases can be easily identified by an odd minor version number: for example, 1.9.0 is a development release. Subsequent releases on the same minor release branch get numbered with 1.9.1, 1.9.2, and so on.
|
|
|
|
|
... | | ... | |