[Kea-announce] Kea 1.7.6, a new development release of Kea, is now available

Michael McNally mcnally at isc.org
Wed Mar 25 19:13:22 UTC 2020


Internet Systems Consortium is pleased to announce the release of Kea 1.7.6.

Kea releases are divided into two branch sequences:

1)  A current stable branch (currently 1.6.x) which receives only important
     bug fixes and is otherwise feature-stable, and

2)  An experimental development branch (currently 1.7.x) where new features
     are added and made available for testing during development, before eventually
     being included in the next stable release branch.

Kea 1.7.6 is the latest release in the experimental development branch.

This is the first release to contain the results of our work to support
multi-threading in Kea and we are eager for feedback on this new feature.
Operators wishing to provide feedback have several options for supplying it:

  1)  if you have discovered a bug you may open an issue in our
      public issue tracker at https://gitlab.isc.org.

  2)  you may participate in discussion on kea-users, an open
      community list operated by ISC.  visit https://lists.isc.org
      if you want to subscribe.

  3)  customers who have an ISC support subscription may open a
      ticket in their support queue.


Michael McNally
ISC Support

-----------------------

# Kea 1.7.6, March 25th 2020, Release Notes

Welcome to Kea 1.7.6, a monthly development release of Kea. This is the
first public release that offers multi-threading support. As with any
other development release, use this with caution. Development releases
are not recommended for production use.

Changes introduced in this version:

1. **Multi-threading**. After more than half a year of development, the
code is now ready for broader testing. We have implemented the `-N`
command line switch that lets you specify number of threads. The special
value of 0 (`-N0`) means Kea should autodetect CPU capabilities and pick
the number for you. Our early tests show a substantial increase in
performance even in the worst cases. We are interested in your feedback,
so please share your observations. Keep in mind that this feature is
experimental; we strongly discourage its use in production networks.
There are some [known
problems](https://gitlab.isc.org/isc-projects/kea/-/wikis/known-issues-li
st). In particular, HA in its current form is not compatible with
multi-threading yet. We hope to address this incompatibility in the
coming weeks. A number of issues were addressed related to MT: #893,
#1016, #1136, #1148.  When running in multi-threaded mode, each client
packet is processed by an individual thread. For logging clarity, you
may wish to add the thread-id to the log statements.  This can be done
by adding "%t" to the logging pattern.  Please see [Logging
pattern](https://kea.readthedocs.io/en/latest/arm/logging.html#the-patter
n-string-option) for more information.

2. **Performance improvements**. Two performance improvements made it
into this release. One flips the order in which Kea does the lease and
host reservations lookups; now the check for a lease for an address is
done first. This should improve performance in case of high pool
utilization (#1124). Another performance fix is related to client
classes defined in host reservations: the classes now can influence
lease allocation. #1139

3. **Resend DDNS updates**. Two new commands - `lease4-resend-ddns` and
`lease6-resend-ddns` - have been implemented. Using those, Kea can now
repeat a DNS update for existing leases. This may prove useful if your
DNS zone file has been corrupted, if Kea timed out while your DNS server
was unreachable, if your TSIG keys were misconfigured, or in a variety
of other failure scenarios. #1106

4. **RADIUS hook update**. We fixed a reported issue in RADIUS
accounting. Kea now sends delegated-ipv6-prefix if that attribute is
available in FreeRADIUS-client. If not, the older behavior, using the
framed-ipv6-prefix attribute, is used. Please make sure you upgrade your
FreeRADIUS-client library as well if you intend to use this feature.
#1140

5. **Leasequery design**. Work has started on leasequery support. As
usual for larger features, the first step is to come up with a design
that explains what code changes are necessary, how we are going to
organize the extra processing, data storage details, etc. This first
step is now [in
review](https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/Basic-Lea
seQuery-Design). Please share your feedback if you're interested in LQ.
#994

6. **Performance testing improvements**. As part of ongoing performance
testing and preparation for multi-threading, we extended our performance
testing tool. Perfdhcp is now able to simulate traffic coming in from
multiple subnets (#931) and can report the results in a format that is
easier to parse (comma- or space-separated values). #1046

7. **Documentation update**. Several aspects of the Kea ARM have been
updated. We now have a separate file with a list of [supported
OSes](https://gitlab.isc.org/isc-projects/kea/-/blob/master/platforms.rst
) (#1055), documentation for BOOTP has been improved (#1107), and the
ARM now has a section about easier native (RPM, deb, and APK) package
installation from [cloudsmith.io](cloudsmith.io/~isc/repos/). #1138

8. **Notable bug fixes**. The shutdown command now can optionally take
an exit-value parameter that Kea will report as status code. This is
used internally when shutting down after failed DB reconnection
attempts, but can be used when doing planned shutdowns (#1115). The
lease file now properly handles situations where there is a comma in the
filename and other fields. In particular, the lease file is now able to
store multiple entries in the user context, which uses JSON syntax that
separates entries with commas. #608

## Changes to Release Model
The Kea project has been in development for several years now, and it
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. As a
result, we decided to change the release cycle. Starting from 1.6.0,
there are two series of releases: stable and development.

Stable releases are what you would expect: stable, released
infrequently, without new features or significant changes, very
well-tested. These can be identified by the middle version number being
even. The current stable release is 1.6.2. If we discover important bugs
that require fixing, we may release 1.6.3, but that will be determined
on a case-by-case basis. The next major stable version will be 1.8.0,
followed by 2.0.0 in the future.

Our team continues development of new features. In particular, we're
tackling the difficult problem of being able to use all available CPU
cores simultaneously. The multi-threading implementation is a complex
task and it is unknown how long it will take before the solution is
stable and ready for a production environment. At the same time, we
continue to receive a stream of requests for small features and bug
fixes. We don't want to force users to wait half a year or more for the
fixes and features that are already done. Therefore, we have started
issuing development releases on a monthly basis. Those are slightly less
well-tested and may have features that are not complete. For example, it
is possible that one of the next releases will provide a configuration
knob to specify the number of threads in multi-threading, but the actual
code that spawns those threads will not yet have been added.

The development releases can be easily identified by the middle version
number being odd: for example, 1.7.5 is a development release. In March
2020 we are releasing 1.7.6, the next development version. Once 1.8.0 is
out, we will continue our development work with 1.9.0, then 1.9.1, and
so on.

Our goal is to make the development release available on the last
Wednesday of each month. There may be exceptions (such as during
holidays), but that's the general plan.

We encourage users to test the development releases and report back
their findings.

For more details on the plan, see ISC's Software Support Policy at
https://kb.isc.org/docs/aa-00896.

## Kea overview
Kea is a DHCP implementation developed by Internet Systems Consortium,
Inc. 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 fully 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.

This text references issue numbers. For more details, visit the Kea
GitLab page at https://gitlab.isc.org/isc-projects/kea/issues.

## License
This version of Kea is released under the Mozilla Public License,
version 2.0.

   https://www.mozilla.org/en-US/MPL/2.0

The premium and subscriber-only hook libraries are provided in source
code form, under the terms of an End User License Agreement (you will
get the source code that you can modify freely, but you are not
permitted to redistribute it).

## Download
Pre-built ISC packages for current versions of the most popular Linux
operating systems are available at:

   https://cloudsmith.io/~isc/repos/

The Kea source and PGP signature for this release may be downloaded from:

   https://www.isc.org/download

The signature was generated with the ISC code signing key which is
available at:

   https://www.isc.org/pgpkey

ISC provides detailed documentation, including installation instructions
and usage tutorials, in the Kea Administrator Reference Manual.
Documentation is included with the installation, at
https://kea.readthedocs.io/en/latest/, or via
https://kb.isc.org/docs/kea-administrator-reference-manual in HTML,
plain text, or PDF formats. ISC maintains a public open source code
tree, a wiki, an issue tracking system, milestone planning, and a
roadmap at https://gitlab.isc.org//isc-projects/kea.

Limitations and known issues with this release can be found at
https://gitlab.isc.org/isc-projects/kea/wikis/known-issues-list.

We ask users of this software to please let us know how it worked for
you and what operating system you tested on. Feel free to share your
feedback on the Kea Users mailing list
(https://lists.isc.org/mailman/listinfo/kea-users).  Also we would like
to hear whether the documentation is adequate and accurate. Please open
tickets in the Kea GitLab project for bugs, documentation omissions and
errors, and enhancement requests. We want to hear from you even if
everything worked.

## Support
Professional support for Kea is available from ISC. We encourage all
professional users to consider this option; Kea development and
maintenance are funded with support subscriptions. For more information
on ISC's Kea and DHCP software support see https://www.isc.org/support/.

Free best-effort support is provided by our user community via a mailing
list. Information on all public email lists is available at
https://www.isc.org/community/mailing-list. If you have any comments or
questions about working with Kea, please share them to the Kea Users
List (https://lists.isc.org/mailman/listinfo/kea-users). Bugs and
feature requests may be submitted via GitLab at
https://gitlab.isc.org/isc-projects/kea/issues.

## Changes
The following summarizes changes and important upgrade notes since the
previous release (1.7.5).

```
1735.	[func]		wlodek
	Added clean output mode to perfdhcp with configurable separator
	for periodic reports.
	(Gutlab #1046)

1734.	[doc]		vicky
	A list of supported OSes is now described in a separate
	platforms.rst file.
	(Gitlab #1055)

1733.	[func]		tmark
	Added lease4-resend-ddns and lease6-resend-ddns commands to
	the Lease Commands hook library.  These commands may be used to
	instruct kea-dhcp4 or kea-dhcp6 to resend a request to update a
	lease's DNS entries to kea-dhcp-ddns.
	(Gitlab #1106)

1732.	[func]		marcin
	Client classes specified within host reservations can be used
	to influence subnet selection within a shared network and pool
	selection within a subnet.
	(Gitlab #1139)

1731.	[func]		razvan
	The NameChangeSender class is thread safe, making DNS updates
	compatible with multi-threading packet processing.
	(Gitlab #1148)

1730.	[func]		razvan
	Added -N command line switch that enables experimental multi-threading
	support. Number of threads can be specified (e.g. -N8) or Kea can be
	told to autodetect number of CPU threads (-N0). This feature is
	experimental. It hasn't been tested extensively and is known to cause
	problems with DDNS and HA. Do not use in production!
	(Gitlab #893)

1729.	[func]		razvan
	The RAII MultiThreadingCriticalSection class is now able to
	automatically stop and start the packet thread pool in order to
	perform server configuration and avoid race conditions in non
	thread safe code.
	(Gitlab #1016)

1728.	[bug]		tmark
	Memfile now supports commas in the hostname and user-context
	columns.  Commas in either column now escaped as "&#x2c" when
	written out, and unescaped when read back in.
	(Gitlab #608)

1727.	[bug]		tmark
	When shutting down due to lost backend database connetivity,
	kea-dhcp4 and kea-dhcp6 processes will exit with a non-zero value.
	This was temporarily altered by #1108. In addition, the "shutdown"
	command now supports an "exit-value" argument.
	(Gitlab #1115)

1726.	[func]		razvan
	Handling SKIP and DROP state in hooks so that the same operation
	is not performed multiple times. Some hooks will throw exceptions
	if the pktX_receive or pktX_send is handled by other hooks, in
	such case, the configuration order of the hooks must be changed.
	(Gitlab #1088)
```

Thank you again to everyone who assisted us in making this release
possible.

We look forward to receiving your feedback.


More information about the Kea-announce mailing list