Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2022-07-08T13:51:02Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2448limits library extensions for lease limiting2022-07-08T13:51:02ZAndrei Pavelandrei@isc.orglimits library extensions for lease limitingAdd lease limiting capabilities to the limits hook library as outlined below:
* [x] Add the ability to configure lease limits.
* [x] Add the packet's client classes to the lease candidate's user context under path `ISC.client-classes` i...Add lease limiting capabilities to the limits hook library as outlined below:
* [x] Add the ability to configure lease limits.
* [x] Add the packet's client classes to the lease candidate's user context under path `ISC.client-classes` in the `leaseX_select` callout.
* [x] Use the `LeaseMgr::checkLimitsX()` functions in the `leaseX_select` callout. Set `NEXT_STEP_DROP` if the limit is exceeded.kea2.2.0 - a new stable branchAndrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2445PostgreSQL schema support for lease limits2022-07-07T11:47:52ZAndrei Pavelandrei@isc.orgPostgreSQL schema support for lease limitsAdd the functionality to support lease limits to the PostgreSQL lease manager as outlined below:
* [x] Create lease count tables to track leases per client class and per subnet
* [x] Create the triggers to update lease counts upon lease...Add the functionality to support lease limits to the PostgreSQL lease manager as outlined below:
* [x] Create lease count tables to track leases per client class and per subnet
* [x] Create the triggers to update lease counts upon lease events: INSERT, UPDATE, DELETE
* [x] Create a function or procedure that compares all the configured lease limits relevant to a packet to all the current lease counts of the respective client classes and subnetskea2.2.0 - a new stable branchAndrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2415hammer.py: provide a valid freeradius-client package for RHEL 82022-05-17T16:30:08ZAndrei Pavelandrei@isc.orghammer.py: provide a valid freeradius-client package for RHEL 8Packaging for RHEL 8 fails with:
```
09:14:16 Traceback (most recent call last):
09:14:16 File "kea/hammer.py", line 2998, in <module>
09:14:16 main()
09:14:16 File "kea/hammer.py", line 2973, in main
09:14:16 build_cmd...Packaging for RHEL 8 fails with:
```
09:14:16 Traceback (most recent call last):
09:14:16 File "kea/hammer.py", line 2998, in <module>
09:14:16 main()
09:14:16 File "kea/hammer.py", line 2973, in main
09:14:16 build_cmd(args)
09:14:16 File "kea/hammer.py", line 2868, in build_cmd
09:14:16 args.ccache_dir, args.pkg_version, args.pkg_isc_version, args.repository_url, pkgs_dir)
09:14:16 File "kea/hammer.py", line 2342, in build_local
09:14:16 pkg_version, pkg_isc_version, repository_url, pkgs_dir)
09:14:16 File "kea/hammer.py", line 2284, in _build_native_pkg
09:14:16 pkg_version, pkg_isc_version, repo_url)
09:14:16 File "kea/hammer.py", line 2105, in _build_rpm
09:14:16 raise NotImplementedError('missing freeradius-client version for %s-%s' % (system, revision))
09:14:16 NotImplementedError: missing freeradius-client version for rhel-8
```
https://jenkins.aws.isc.org/job/kea-dev/job/pkg/775/execution/node/68/log/kea2.1.6Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2339Memory leak in HA scenario with backup server down2023-09-07T14:02:26ZBranimir RajtarMemory leak in HA scenario with backup server down---
name: Memory leak in HA scenario with backup server down
about: Memory loss is created on running instances
---
**Describe the bug**
HA mode is configured with three servers (primary, secondary, backup) and is serving clients. Whe...---
name: Memory leak in HA scenario with backup server down
about: Memory loss is created on running instances
---
**Describe the bug**
HA mode is configured with three servers (primary, secondary, backup) and is serving clients. When the backup server becomes unavailable, the primary and secondary experience a continuous memory leak which is manifested as a continuous increase in RSS memory use for the isc-kea-dhcp4-server process. The size of the memory leak is in direct correlation with the number of active clients - the larger number, the greater the memory leak. Once the backup server is deleted from the configuration or it becomes active again, there is no more memory increase, but the old memory is not freed.
**To Reproduce**
Steps to reproduce the behavior:
1. Run KEA (DHCP4 only) in HA scenario with two load-balancing servers (primary and secondary) and a single backup server
2. Start serving clients (40k in our scenario) and monitoring RSS usage for the KEA server process
3. Disable backup server
4. Verify that RSS usage is increasing continuously
5. Enable backup server
6. Verify that RSS usage is stable
**Expected behavior**
The servers should not have any memory leaks.
**Environment:**
- Kea version: 1.8.2, 2.0.2
- OS: Ubuntu 18.04
- Memfile
- libdhcp_lease_cmds, libdhcp_stat_cmds, libdhcp_ha
**Additional Information**
```
{
"Dhcp4": {
"dhcp-queue-control": {
"enable-queue": true,
"queue-type": "kea-ring4",
"capacity": 256
},
"interfaces-config": {
"interfaces": [
"eth1"
],
"dhcp-socket-type": "udp"
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea-dhcp4-ctrl.sock"
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/kea/dhcp4.leases",
"lfc-interval": 3600,
"port": 0
},
"expired-leases-processing": {
"reclaim-timer-wait-time": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
"renew-timer": 60,
"rebind-timer": 100,
"valid-lifetime": 120,
"option-data": [],
"hooks-libraries": [
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so",
"parameters": {}
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_stat_cmds.so"
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [
{
"this-server-name": "server3",
"mode": "load-balancing",
"heartbeat-delay": 3000,
"max-response-delay": 7000,
"max-ack-delay": 7000,
"max-unacked-clients": 20,
"peers": [
{
"name": "server2",
"url": "http://<XXX>:8080/",
"role": "secondary",
"auto-failover": true
},
{
"name": "server1",
"url": "http://<YYY>:8080/",
"role": "primary",
"auto-failover": true
},
{
"name": "server3",
"url": "http://<ZZZ>:8080/",
"role": "backup",
"auto-failover": true
}
]
}
]
}
}
],
"option-def": [
{
"name": "classless-static-route",
"code": 121,
"space": "dhcp4",
"type": "record",
"array": true,
"record-types": "uint8, uint8"
}
],
"client-classes": [
// anonymized
],
"subnet4": [
// anonymized
],
"reservations": [],
"loggers": [
{
"name": "kea-dhcp4",
"output_options": [
{
"output": "syslog"
}
],
"severity": "error",
"debuglevel": 0
}
]
}
}
```
**Contacting you**
Email/Github, telephone is available after contactnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/21962.1.1 release2022-01-19T07:50:33ZAndrei Pavelandrei@isc.org2.1.1 release---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess...---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of those checks and updates can be made before the actual freeze.
1. Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.aws.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/Kea_20Build_20Checks/)
1. [x] Check [Performance Test Results](https://jenkins.isc.org/job/kea-dev/job/performance/KeaPerformanceReport/) in Jenkins for drops in performance.
1. Check versioning, ask the development team if:
- the library versions are being updated
- `KEA_HOOKS_VERSION` is being updated
- [x] create an issue for that for developers in Gitlab
- script: [./tools/bump-lib-versions.sh](https://gitlab.isc.org/isc-projects/kea/-/blob/master/tools/bump-lib-versions.sh) Kea-q.w.e Kea-a.b.c (where `a.b.c` is the version to be released and `q.w.e` is the version previous to that)
1. Prepare Release Notes
1. [x] Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should be created under "release notes" directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-2.1.0
1. [ ] Finish release notes and conduct its review
1. [ ] Run [release-pkgs-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-upload-internal/) and [release-pkgs-check-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check-internal/) to test repositories for correctness.
1. If a new Cloudsmith repository is used, make sure access tokens have been been synchronized from previous Cloudsmith repositories and to the [check-pkgs.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/pkgs-check/check-pkgs.py) QA tool.
1. [x] Check if ReadTheDocs can build Kea documentation.
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds) and wait for the build to complete.
The following steps may involve changing files in the repository.
1. [x] Run [update-code-for-release.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/update-code-for-release.py) <br>
Example command: `GITLAB_KEA_TOKEN='...' GITLAB_KEA_PREMIUM_TOKEN='...' ./update-code-for-release.py 1.9.7 'Apr 28, 2021' ~/isc/repos/kea/` <br>
The script:
- creates Gitlab issue and MR for release changes
- adds release entries to ChangeLogs
- regenerates BNF grammar
- regenerates documentation
- regenerates messages
- reorders messages in alphabetical order
- regenerates parsers
- updates copyright dates
- pushes the changes to MR
1. Check manually User's Guide sections:
1. Chapter 1. Introduction
1. [x] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [x] Did we add any additional 3rd party software? Update if needed
1. [x] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. Chapter 2. Quick Start
1. [x] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. Chapter 3. Installation
1. [x] Check installation hierarchy (this is also automatically checked at the end of [ut-extended job](https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/))
1. [x] Check and update Build Requirements
1. [x] Check configure options against what `./configure -h` says
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whitespaces, etc.
1. [x] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [x] If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the MR to master.
## Build selection, tarballs upload and sanity checks
This is the last moment to freeze code! :snowflake:
1. [x] Go to [tarball-internal](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/) Jenkins job and pick the last tarball built - it will be a release candidate.
1. [x] Check tarball before requesting sanity checks from the development team.
1. Download tarballs from picked Jenkins build
1. Check hook libraries.
1. Are there any new hook libraries installed in this release?
1. Are they in the proper tarball? Premium or subscription?
1. Do they have their own package?
1. Check sizes - is the new package reasonable?
1. Check installation tree, compare it with the previous release
1. Check installed libraries.
1. which were updated? (save results)
1. Do any of the libraries from the current release have lower version than in the previous release?
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if all of the installed binaries has man page
1. if not, is it in the tarball?
1. are man page up-to-date?
1. Check if documentation is properly formatted, has correct versions and dates.
1. it's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid
1. [x] Upload tarballs to repo.isc.org using Jenkins and send sanity checks request.
1. Go to [release-tarball-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick:
1. rc1 if this is the first selected build for release, it will push the selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
1. next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in an error)
1. final if the last rc number was ok, this will push the selected tarball to repo.isc.org, to a directory with no suffixes
1. Submit the job that will automatically:
1. Upload the tarballs <br>
and if this is not the final version:
1. Create a GitLab issue for sanity checks, put there the announcement
1. Send Sanity Checks announcement via email to dhcp-team@isc.org and to DHCP channel on Mattermost.<br>
The announcement includes:
- a link to chapter 4 Sanity Checks of the release process: [KeaReleaseProcess - SanityChecks](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks)
- a link to the GitLab issue
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
## Releasing Tarballs and Packages
1. [x] Update Release Notes with ChangeLog entries
1. [x] Upload final RPM & DEB packages to cloudsmith.io
1. Go to [release-pkgs-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-upload-internal/).
1. Click "Build with Parameters" link
1. Pick your selected pkg build in Packages field, and select `PrivPubRepos: "both"`, `TestProdRepos: "production"` and click Build button.
1. When it finishes run check: [releases-pkgs-check-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check-internal/).
1. [x] Upload final tarballs to repo.isc.org
1. Go to [release-tarball-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick final <br>
This job will also:
- open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) requesting signing final tarballs on repo.isc.org
- create Git tags `Kea-a.b.c` in Kea main and premium repositories
- send a signing request issue link on the DHCP Mattermost channel
1. [x] Update ReadTheDocs
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. For stable releases, change the default version to point to this stable release.
1. [x] Mark Jenkins jobs with release artifacts to be kept forever: <br>
Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button: <br>
1. [tarball-internal job](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/)
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/)
1. [x] Create an issue and a merge request to bump up Kea version in `configure.ac` to next development version which could be, based on just released version `a.b.c`:
* `a.b.z-git` where `z == c + 1` or
* `a.y.0-git` where `y == b + 1` or
* `x.1.0-git` where `x == a + 1`
1. [x] Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist issue.
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *kea-announce*.
- [ ] ***(Support)*** Write email to *kea-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [ ] ***(Support)*** If it is a new `major.minor` version, SWENG will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Then update support customers that this new private repo exists.
- [x] ***(Support)*** Update tickets in case of waiting for support customers.
- [ ] ***(QA)*** Inform Marketing of the release.
- [ ] ***(Marketing)*** If a new Cloudsmith repository is used, update the Zapier scripts.
- [ ] ***(Marketing)*** Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version.
- [ ] ***(Marketing)*** Announce on social media.
- [ ] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [ ] ***(Marketing)*** Write blog article (if a major release).
- [ ] ***(Marketing)*** Update [Kea page on web site if any new hooks](https://www.isc.org/kea/).
- [ ] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [ ] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
- [ ] ***(Marketing)*** Update [Kea documentation page in KB](https://kb.isc.org/docs/en/kea-administrator-reference-manual).kea2.1.1Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2158Inconsistent documentation for conflict resolution between 8.2.18 and 13.1.22022-02-18T11:36:47ZShawn RouthierInconsistent documentation for conflict resolution between 8.2.18 and 13.1.2The documentation for the DHCP-DDNS server is out of sync with the documentation for Kea v4.
In 13.1.2 the text states that conflict resolution is always performed while 8.2.18 introduces
the option to disable conflict resolution.The documentation for the DHCP-DDNS server is out of sync with the documentation for Kea v4.
In 13.1.2 the text states that conflict resolution is always performed while 8.2.18 introduces
the option to disable conflict resolution.kea2.1.3Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/21462.1.0 release2021-11-08T08:08:13ZAndrei Pavelandrei@isc.org2.1.0 release---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess...---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of those checks and updates can be made before the actual freeze.
1. Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.aws.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/Kea_20Build_20Checks/)
1. [x] Check [Performance Test Results](https://jenkins.isc.org/job/kea-dev/job/performance/KeaPerformanceReport/) in Jenkins for drops in performance.
1. Check versioning, ask the development team if:
- the library versions are being updated
- `KEA_HOOKS_VERSION` is being updated
- [x] create an issue for that for developers in Gitlab
- script: [./tools/bump-lib-versions.sh](https://gitlab.isc.org/isc-projects/kea/-/blob/master/tools/bump-lib-versions.sh) Kea-q.w.e Kea-a.b.c (where `a.b.c` is the version to be released and `q.w.e` is the version previous to that)
1. Prepare Release Notes
1. [x] Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should be created under "release notes" directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-1.9.2
1. [ ] Finish release notes and conduct its review
1. [ ] Run [release-pkgs-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-upload-internal/) and [release-pkgs-check-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check-internal/) to test repositories for correctness.
The following steps may involve changing files in the repository.
1. [x] Run [update-code-for-release.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/update-code-for-release.py) <br>
Example command: `GITLAB_KEA_TOKEN='...' GITLAB_KEA_PREMIUM_TOKEN='...' ./update-code-for-release.py 1.9.7 'Apr 28, 2021' ~/isc/repos/kea/` <br>
The script:
- creates a Kea issue and MR for release changes,
- runs several updating scripts
- pushes the changes to MR
1. Check manually User's Guide sections:
1. Chapter 1. Introduction
1. [x] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [x] Did we add any additional 3rd party software? Update if needed
1. [x] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. Chapter 2. Quick Start
1. [x] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. Chapter 3. Installation
1. [x] Check installation hierarchy (this is also automatically checked at the end of [ut-extended job](https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/))
1. [x] Check and update Build Requirements
1. [x] Check configure options against what `./configure -h` says
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whitespaces, etc.
1. [x] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [x] If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the MR to master.
## Build selection, tarballs upload and sanity checks
This is the last moment to freeze code! :snowflake:
1. [x] Go to [tarball-internal](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/) Jenkins job and pick the last tarball built - it will be a release candidate.
1. [x] Check tarball before requesting sanity checks from the development team.
1. Download tarballs from picked Jenkins build
1. Check sizes - is the new package reasonable?
1. Check installation tree, compare it with the previous release
1. Check installed lib versions
1. which were updated? (save results)
1. any of the lib from current release has lower number then corresponding lib from previous release? (!)
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if all of the installed binaries has man page
1. if not, is it in the tarball?
1. are man page up-to-date?
1. Check if documentation is properly formatted, has correct versions and dates.
1. it's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid
1. [x] Upload tarballs to repo.isc.org using Jenkins and send sanity checks request.
1. Go to [release-tarball-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick:
1. rc1 if this is the first selected build for release, it will push the selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
1. next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in an error)
1. final if the last rc number was ok, this will push the selected tarball to repo.isc.org, to a directory with no suffixes
1. Submit the job that will automatically:
1. Upload the tarballs <br>
and if this is not the final version:
1. Create a GitLab issue for sanity checks, put there the announcement
1. Send Sanity Checks announcement via email to dhcp-team@isc.org and to DHCP channel on Mattermost.<br>
The announcement includes:
- a link to chapter 4 Sanity Checks of the release process: [KeaReleaseProcess - SanityChecks](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks)
- a link to the GitLab issue
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
## Releasing Tarballs and Packages
1. [x] Update Release Notes with ChangeLog entries
1. [x] Upload final RPM & DEB packages to cloudsmith.io
1. Go to [release-pkgs-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-upload-internal/).
1. Click "Build with Parameters" link
1. Pick your selected pkg build in Packages field, and select `PrivPubRepos: "both"`, `TestProdRepos: "production"` and click Build button.
1. When it finishes run check: [releases-pkgs-check-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check-internal/).
1. [x] Upload final tarballs to repo.isc.org
1. Go to [release-tarball-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick final <br>
This job will also:
- open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) requesting signing final tarballs on repo.isc.org
- create Git tags `Kea-a.b.c` in Kea main and premium repositories
- send a signing request issue link on the DHCP Mattermost channel
1. [x] Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist issue.
1. [x] Mark Jenkins jobs with release artifacts to be kept forever: <br>
Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button: <br>
1. [tarball-internal job](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/)
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/)
1. [x] Update ReadTheDocs
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. For stable releases, change the default version to point to this stable release.
### On the Day of Public Release
- [ ] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *kea-announce*.
- [ ] ***(Support)*** Write email to *kea-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [x] ***(Support)*** If it is a new major version, SWENG will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Then update support customers that this new private repo exists.
- [ ] ***(Support)*** Update tickets in case of waiting for support customers.
- [ ] ***(QA)*** Inform Marketing of the release.
- [ ] ***(Marketing)*** Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version.
- [ ] ***(Marketing)*** Announce on social media.
- [ ] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [ ] ***(Marketing)*** Write blog article (if a major release).
- [ ] ***(Marketing)*** Update [Kea page on web site if any new hooks](https://www.isc.org/kea/).
- [ ] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [ ] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
- [ ] ***(Marketing)*** Update [Kea documentation page in KB](https://kb.isc.org/docs/en/kea-administrator-reference-manual).
## Post-Release, But Before Code Unfreeze
- [x] Bump up Kea version in `configure.ac` to next development version which could be, based on just released version `a.b.c`:
* `a.b.z-git` where `z == c + 1` or
* `a.y.0-git` where `y == b + 1` or
* `x.1.0-git` where `x == a + 1`kea2.1.0Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.org2021-10-27https://gitlab.isc.org/isc-projects/kea/-/issues/2131revisit and extend D2 update retry code2022-02-25T12:09:25ZFrancis Dupontrevisit and extend D2 update retry codeThe waiting delay between two attempts is not clear and for GSS-TSIG to be able to set the number of retries is requested.
This ticket should stay in the core code. Note the idea to save and restore the NCR queue is not considered here ...The waiting delay between two attempts is not clear and for GSS-TSIG to be able to set the number of retries is requested.
This ticket should stay in the core code. Note the idea to save and restore the NCR queue is not considered here (it has its own ticket #1801).
Opening a design phaseoutstandingFrancis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2068Performance degradation in hot standby in HA2021-09-23T15:13:38ZTomek MrugalskiPerformance degradation in hot standby in HA@wlodek recently implemented extended HA stability tests and the results are worrisome. It seems that there is a huge performance degradation observed in the following scenarios:
* hotstandby memfile v4 (after 40s)
* hotstandby memfile ...@wlodek recently implemented extended HA stability tests and the results are worrisome. It seems that there is a huge performance degradation observed in the following scenarios:
* hotstandby memfile v4 (after 40s)
* hotstandby memfile v6 (after 10s)
* hotstandby postgresql v4 (after 46s)
* hotstandby postgresql v6 (erratic, degradation over a period between 55 and 65s, but also slow degradation from 6000 acks/s down to 5500s in the initial 55s)
* loadbalancing postgresql v4 (43s)
Open the report [report-ha-1.9.11-master.html](/uploads/6413385966bb41e93076f347bc53f561/report-ha-1.9.11-master.html), and go to `HA stability` tab. For example, see "ha multi hotstandby memfile v4". These are charts 1-A and 1-B. Note the violet line (ACK-received), which behaves correctly for roughly 40 seconds (~11k ACKs/sec) and then degrades rapidly to 3k ACKs/sec.
![Screenshot_2021-08-31_at_10.27.04](/uploads/75d547e6032782d3d7bd5d5196f1207e/Screenshot_2021-08-31_at_10.27.04.png)
@wlodek will provide more details, including configs, once he gets back to office.kea2.0.0 (formerly 1.9.12)Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2066Memory leak in several HA scenarios2022-03-03T15:08:19ZTomek MrugalskiMemory leak in several HA scenarios@wlodek recently implemented extended HA stability tests and the results are worrisome. It seems that there is a memory leak in the following scenarios:
* passive backup memfile v4
* passive backup memfile v6
* hotstandby memfile v6
* h...@wlodek recently implemented extended HA stability tests and the results are worrisome. It seems that there is a memory leak in the following scenarios:
* passive backup memfile v4
* passive backup memfile v6
* hotstandby memfile v6
* hotstandby postgresql v4
* hotstandby postgresql v6
Open the report [report-ha-1.9.11-master.html](/uploads/6413385966bb41e93076f347bc53f561/report-ha-1.9.11-master.html), and go to `HA stability` tab. For example, see "passive backup memfile v4". There are two diagrams 13-A (shows traffic) and 13-B that shows CPU and memory utilization. Note the primary mem usage. The machine has 64G ram. The memory usage grows stadily to over 25% (16GB) when the test concludes after 800 seconds (specified test duration). Other scenarios listed above show similar behaviors. @wlodek will provide more details, including configs, once he gets back to office.
UPDATE: The results above were run on master, after 1.9.11 code freeze and later repeated on 1.9.8 release, which showed similar problems.
![Screenshot_2021-08-31_at_10.56.55](/uploads/56e3157583f1c06f8318ee01fd9efb85/Screenshot_2021-08-31_at_10.56.55.png)kea2.0.0 (formerly 1.9.12)Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/2037Improve expired leases reclamation query for PostgreSQL2022-11-02T15:10:41ZThomas MarkwalderImprove expired leases reclamation query for PostgreSQLExtended performance testing revealed cyclic slow downs that correspond to expired lease reclamation. The MySQL query was doing full table scans, this was mitigated under #2030. We need to examine PostgreSQL performance and see if it ca...Extended performance testing revealed cyclic slow downs that correspond to expired lease reclamation. The MySQL query was doing full table scans, this was mitigated under #2030. We need to examine PostgreSQL performance and see if it can be improved.backlogMarcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/19461.9.9 release checklist2021-07-01T06:49:45ZAndrei Pavelandrei@isc.org1.9.9 release checklist---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess...---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of those checks and updates can be made before the actual freeze.
1. Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.aws.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/Kea_20Build_20Checks/)
1. [x] Check [Performance Test Results](https://jenkins.isc.org/job/kea-dev/job/performance/KeaPerformanceReport/) in Jenkins for drops in performance.
1. Check versioning, ask the development team if:
- the library versions are being updated
- `KEA_HOOKS_VERSION` is being updated
- [x] create an issue for that for developers in Gitlab
- script: [./tools/bump-lib-versions.sh](https://gitlab.isc.org/isc-projects/kea/-/blob/master/tools/bump-lib-versions.sh) Kea-q.w.e Kea-a.b.c (where `a.b.c` is the version to be released and `q.w.e` is the version previous to that)
1. Prepare Release Notes
1. [x] Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should be created under "release notes" directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-1.9.2
1. [x] Finish release notes and conduct its review
1. [x] Run [release-pkgs-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-upload-internal/) and [release-pkgs-check-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check-internal/) to test repositories for correctness.
The following steps may involve changing files in the repository.
1. [x] Run [update-code-for-release.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/update-code-for-release.py) <br>
Example command: `GITLAB_KEA_TOKEN='...' GITLAB_KEA_PREMIUM_TOKEN='...' ./update-code-for-release.py 1.9.7 'Apr 28, 2021' ~/isc/repos/kea/` <br>
The script:
- creates a Kea issue and MR for release changes,
- runs several updating scripts
- pushes the changes to MR
1. Check manually User's Guide sections:
1. Chapter 1. Introduction
1. [x] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [x] Did we add any additional 3rd party software? Update if needed
1. [x] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. Chapter 2. Quick Start
1. [x] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. Chapter 3. Installation
1. [x] Check installation hierarchy (this is also automatically checked at the end of [ut-extended job](https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/))
1. [x] Check and update Build Requirements
1. [x] Check configure options against what `./configure -h` says
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whitespaces, etc.
1. [x] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [x] If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the MR to master.
## Build selection, tarballs upload and sanity checks
This is the last moment to freeze code! :snowflake:
1. [x] Go to [tarball-internal](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/) Jenkins job and pick the last tarball built - it will be a release candidate.
1. [x] Check tarball before requesting sanity checks from the development team.
1. Download tarballs from picked Jenkins build
1. Check sizes - is the new package reasonable?
1. Check installation tree, compare it with the previous release
1. Check installed lib versions
1. which were updated? (save results)
1. any of the lib from current release has lower number then corresponding lib from previous release? (!)
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if all of the installed binaries has man page
1. if not, is it in the tarball?
1. are man page up-to-date?
1. Check if documentation is properly formatted, has correct versions and dates.
1. it's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid
1. [x] Upload tarballs to repo.isc.org using Jenkins and send sanity checks request.
1. Go to [release-tarball-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick:
1. rc1 if this is the first selected build for release, it will push the selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
1. next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in an error)
1. final if the last rc number was ok, this will push the selected tarball to repo.isc.org, to a directory with no suffixes
1. Submit the job that will automatically:
1. Upload the tarballs <br>
and if this is not the final version:
1. Create a GitLab issue for sanity checks, put there the announcement
1. Send Sanity Checks announcement via email to dhcp-team@isc.org and to DHCP channel on Mattermost.<br>
The announcement includes:
- a link to chapter 4 Sanity Checks of the release process: [KeaReleaseProcess - SanityChecks](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks)
- a link to the GitLab issue
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
## Releasing Tarballs and Packages
1. [x] Update Release Notes with ChangeLog entries
1. [x] Upload final RPM & DEB packages to cloudsmith.io
1. Go to [release-pkgs-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-upload-internal/).
1. Click "Build with Parameters" link
1. Pick your selected pkg build in Packages field, and select `PrivPubRepos: "both"`, `TestProdRepos: "production"` and click Build button.
1. When it finishes run check: [releases-pkgs-check-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check-internal/).
1. [x] Upload final tarballs to repo.isc.org
1. Go to [release-tarball-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick final <br>
This job will also:
- open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) requesting signing final tarballs on repo.isc.org
- create Git tags `Kea-a.b.c` in Kea main and premium repositories
- send a signing request issue link on the DHCP Mattermost channel
1. [x] Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist issue.
1. [x] Mark Jenkins jobs with release artifacts to be kept forever: <br>
Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button: <br>
1. [tarball-internal job](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/)
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/)
1. [x] Update ReadTheDocs
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. For stable releases, change the default version to point to this stable release.
### On the Day of Public Release
- [ ] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *kea-announce*.
- [ ] ***(Support)*** Write email to *kea-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [ ] ***(Support)*** If it is a new major version, SWENG will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Then update support customers that this new private repo exists.
- [x] ***(Support)*** Update tickets in case of waiting for support customers.
- [ ] ***(QA)*** Inform Marketing of the release.
- [ ] ***(Marketing)*** Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version.
- [ ] ***(Marketing)*** Announce on social media.
- [ ] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [ ] ***(Marketing)*** Write blog article (if a major release).
- [ ] ***(Marketing)*** Update [Kea page on web site if any new hooks](https://www.isc.org/kea/).
- [ ] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [ ] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
- [ ] ***(Marketing)*** Update [Kea documentation page in KB](https://kb.isc.org/docs/en/kea-administrator-reference-manual).
## Post-Release, But Before Code Unfreeze
- [x] Bump up Kea version in `configure.ac` to next development version which could be, based on just released version `a.b.c`:
* `a.b.z-git` where `z == c + 1` or
* `a.y.0-git` where `y == b + 1` or
* `x.1.0-git` where `x == a + 1`kea1.9.9https://gitlab.isc.org/isc-projects/kea/-/issues/1896start reporting coverage in CI2021-07-26T15:33:41ZTomek Mrugalskistart reporting coverage in CIWe'd like to improve Kea public perception as a stable and responsible project that large organizations can rely on. One way to achieve that is get a high score on [Best Practices CII](https://bestpractices.coreinfrastructure.org/en/proj...We'd like to improve Kea public perception as a stable and responsible project that large organizations can rely on. One way to achieve that is get a high score on [Best Practices CII](https://bestpractices.coreinfrastructure.org/en/projects/98?criteria_level=2#quality) page.
The page can be confusing at first. There are 3 certificate levels: passing (we got that), silver and gold. For each level, there are multiple areas with specific requirements. The coverage is covered on gold level in Quality section.
So, the long term goal is to fulfill those requirements:
- automated test suite(s) that provide at least 90% statement coverage
- automated test suite(s) that provide at least 80% branch coverage
It's a complex task and we most likely don't have coverage that is this high. So let's aim for something more modest. The goal here is to start measuring statement and branch coverage.
Couple useful sources to consider:
- BIND 9 tests coverage and reports it on gitlab: https://gitlab.isc.org/isc-projects/bind9/-/graphs/main/charts (we don't have to do it the same way, it's just a pointer)
- https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/302/cobertura/
- we have an old job on Jenkins for coverage: https://jenkins.isc.org/view/All/job/kea-master-coverage-internal/ it predates Jenkins files, but there may be some useful scripts to be salvaged therekea1.9.10Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/1822update release checklist template2021-04-23T10:56:23ZMichal Nowikowskiupdate release checklist templateUpdated step for changing or updating source code so it uses new script update-code-for-release.py.Updated step for changing or updating source code so it uses new script update-code-for-release.py.kea1.9.7Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/18191.9.7 release checklist2021-05-10T10:12:04ZMichal Nowikowski1.9.7 release checklist---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess...---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of those checks and updates can be made before actual freeze.
1. Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.aws.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/Kea_20Build_20Checks/)
1. [ ] Check [Performance Test Results](https://jenkins.isc.org/job/kea-dev/job/performance/KeaPerformanceReport/) in Jenkins for drops in performance.
1. Check versioning, ask the development team if:
- the library versions are being updated
- `KEA_HOOKS_VERSION` is being updated
- [x] create an issue for that for developers in Gitlab
- script: [./tools/bump-lib-versions.sh](https://gitlab.isc.org/isc-projects/kea/-/blob/master/tools/bump-lib-versions.sh) Kea-q.w.e Kea-a.b.c (where `a.b.c` is the version to be released and `q.w.e` is the version previous to that)
1. Prepare Release Notes
1. [x] Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should be created under "release notes" directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-1.9.2
1. [x] Finish release notes and conduct its review
1. [x] Run [release-pkgs-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-upload-internal/) and [release-pkgs-check-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check-internal/) to test repositories for correctness.
The following steps may involve changing files in the repository.
1. [x] Run [update-code-for-release.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/update-code-for-release.py) <br>
Example command: `GITLAB_KEA_TOKEN='...' GITLAB_KEA_PREMIUM_TOKEN='...' ./update-code-for-release.py 1.9.7 'Apr 28, 2021' ~/isc/repos/kea/` <br>
The script:
- creates a Kea issue and MR for release changes,
- runs several updating scripts
- pushes the changes to MR
1. Check manually User's Guide sections:
1. Chapter 1. Introduction
1. [x] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [x] Did we add any additional 3rd party software? Update if needed
1. [x] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. Chapter 2. Quick Start
1. [x] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. Chapter 3. Installation
1. [x] Check installation hierarchy
1. [x] Check and update Build Requirements
1. [x] Check configure options against what `./configure -h` says
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whitspaces, etc.
1. [x] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [x] If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the MR to master.
## Build selection, tarballs upload and sanity checks
This is the last moment to freeze code! :snowflake:
1. [x] Go to [tarball-internal](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/) Jenkins job and pick last tarball built - it will be a release candidate.
1. [x] Check tarball before requesting sanity checks from the development team.
1. Download tarballs from picked Jenkins build
1. Check sizes - is new package reasonable?
1. Check installation tree, compare it with previous release
1. Check installed lib versions
1. which were updated? (save results)
1. any of the lib from current release has lower number then corresponding lib from previous release? (!)
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if all of installed binaries has man page
1. if not, is it in the tarball?
1. are man page up-to-date?
1. Check if documentation is properly formatted, has correct versions and dates.
1. it's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid
1. [x] Upload tarballs to repo.isc.org using Jenkins
1. Go to [release-tarball-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick:
1. rc1 if this is the first selected build for release, it will push selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
1. next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in error)
1. final if the last rc number was ok, this will push the selected tarball to repo.isc.org, to a directory with no suffixes
1. Submit the job that will automatically:
1. Upload the tarballs upload <br>
and if this is not the final version:
1. Create a GitLab issue for sanity checks, put there the announcement
1. Send Sanity Checks announcement via email to dhcp-team@isc.org and to DHCP channel on Mattermost.<br>
The announcement includes:
- a link to chapter 4 Sanity Checks of the release process: [KeaReleaseProcess - SanityChecks](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks)
- a link to an issue created in the previous step
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
## Releasing Tarballs and Packages
1. [x] Update Release Notes with ChangeLog entries
1. [x] Upload final RPM & DEB packages to cloudsmith.io
1. Go to [release-pkgs-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-upload-internal/).
1. Click "Build with Parameters" link
1. Pick your selected pkg build in Packages field, and select `PrivPubRepos: "both"`, `TestProdRepos: "production"` and click Build button.
1. When it finishes run check: [releases-pkgs-check-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check-internal/).
1. [x] Upload final tarballs to repo.isc.org
1. Go to [release-tarball-upload-internal](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick final <br>
This job will also: <br>
- open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) requesting signing final tarballs on repo.isc.org
- send a signing request issue link on the DHCP Mattermost channel
- create Git tags `Kea-a.b.c` in Kea main and premium repositories
1. [x] Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist.
1. Mark Jenkins jobs with release artifacts to be kept forever: <br>
Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button: <br>
1. [x] [tarball-internal job](https://jenkins.aws.isc.org/job/kea-dev/job/tarball-internal/)
1. [x] [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/)
1. Update ReadTheDocs
1. [x] Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. [x] Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. [x] For stable releases, change the default version to point to this stable release.
### On the Day of Public Release
- [ ] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [ ] ***(Support)*** Place tarballs in public location on FTP site.
- [ ] ***(Support)*** Publish links to downloads on ISC website.
- [ ] ***(Support)*** Write release email to *kea-announce*.
- [ ] ***(Support)*** Write email to *kea-users* (if a major release).
- [ ] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [ ] ***(Support)*** If it is a new major version, sweng will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Then update support customers that this new private repo exists.
- [ ] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Inform Marketing of the release.
- [ ] ***(Marketing)*** Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version.
- [x] ***(Marketing)*** Announce on social media.
- [x] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(Marketing)*** Update [Kea page on web site if any new hooks](https://www.isc.org/kea/).
- [x] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [x] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
- [x] ***(Marketing)*** Update [Kea documentation page in KB](https://kb.isc.org/docs/en/kea-administrator-reference-manual).
## Post-Release, But Before Code Unfreeze
- [x] Bump up Kea version in `configure.ac` to next development version which could be, based on just released version `a.b.c`:
* `a.b.z-git` where `z == c + 1` or
* `a.y.0-git` where `y == b + 1` or
* `x.1.0-git` where `x == a + 1`kea1.9.7https://gitlab.isc.org/isc-projects/kea/-/issues/17711.9.6 release checklist2021-03-31T17:57:39ZAndrei Pavelandrei@isc.org1.9.6 release checklist---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess...---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of those checks and updates can be made before actual freeze.
1. Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.isc.org/job/kea-dev/job/tarball-internal/Kea_20Build_20Checks/)
1. [x] Check [Performance Test Results](https://jenkins.isc.org/job/kea-dev/job/performance/KeaPerformanceReport/) in Jenkins for drops in performance.
1. Check versioning, ask the development team if:
- the library versions are being updated
- `KEA_HOOKS_VERSION` is being updated
- [x] create an issue for that for developers in Gitlab
- script: [./tools/bump-lib-versions.sh](https://gitlab.isc.org/isc-projects/kea/-/blob/master/tools/bump-lib-versions.sh) Kea-q.w.e Kea-a.b.c (where `a.b.c` is the version to be released and `q.w.e` is the version previous to that)
1. Prepare Release Notes
1. [x] Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should be created under "release notes" directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-1.9.2
1. [x] Finish release notes and conduct its review
1. [x] Run [release-pkgs-upload-internal](https://jenkins.isc.org/job/kea-dev/job/release-pkgs-upload-internal/) and [release-pkgs-check-internal](https://jenkins.isc.org/job/kea-dev/job/release-pkgs-check-internal/) to test repositories for correctness.
The following steps may involve changing files in the repository.
1. [x] Create a Kea issue for code changes that will be made due to the following checks:
1. Check User's Guide sections:
1. Chapter 1. Introduction
1. [x] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [x] Did we add any additional 3rd party software? Update if needed
1. [x] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. Chapter 2. Quick Start
1. [x] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. Chapter 3. Installation
1. [x] Check installation hierarchy
1. [x] Check and update Build Requirements
1. [x] Check configure options against what `./configure -h` says
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whatspaces, etc.
1. [x] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [x] Update information in sources about copyright dates, new version, etc, script: [prepare_kea_release.sh](https://gitlab.isc.org/isc-private/qa-dhcp/blob/master/kea/build/prepare_kea_release.sh).
1. [x] Regenerate parsers using docs.isc.org, script: [regen-parsers.sh](https://gitlab.isc.org/isc-private/qa-dhcp/blob/master/kea/build/regen-parsers.sh).
If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the branch to master.
## Build selection and upload package
This is the last moment to freeze code! :snowflake:
1. [x] Go to [tarball-internal](https://jenkins.isc.org/job/kea-dev/job/tarball-internal/) Jenkins job and pick last tarball built - it will be a release candidate.
1. [x] Check tarball before requesting sanity checks from the development team.
1. Download tarballs from picked Jenkins build
1. Check sizes - is new package reasonable?
1. Check installation tree, compare it with previous release
1. Check installed lib versions
1. which were updated? (save results)
1. any of the lib from current release has lower number then corresponding lib from previous release? (!)
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if all of installed binaries has man page
1. if not, is it in the tarball?
1. are man page up-to-date?
1. Check if documentation is properly formatted, has correct versions and dates.
1. it's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid
1. [x] Upload tarballs to repo.isc.org using Jenkins
1. Go to [release-tarball-upload-internal](https://jenkins.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick:
1. rc1 if this is the first selected build for release, it will push selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
1. next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in error)
1. final if the last rc number was ok, this will push selected tarball to repo.isc.org, to a directory with no suffixes
1. [x] If none of the results force you to fix and rebuild package, send sanity checks request if not already triggered automatically by `release-tarball-upload-internal`.
## Sanity Checks
1. [x] Create Sanity Checks announcement, put there:
- a link to chapter 4 Sanity Checks of the release process: [KeaReleaseProcess - SanityChecks](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks)
- a link to an issue created in next step
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
1. [x] Create a GitLab issue for sanity checks, put there the announcement
1. [x] Send the announcement to dhcp-team@isc.org
## Releasing Tarballs
1. [x] Update Release Notes with ChangeLog entries
1. [x] Upload final tarballs to repo.isc.org
1. Go to [release-tarball-upload-internal](https://jenkins.isc.org/job/kea-dev/job/release-tarball-upload-internal/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick final
1. [x] When the upload is completed then copy SHA checksums from the log and write an email to signers@isc.org requesting signatures
of final tarballs on repo.isc.org indicating release directories. Attach SHA checksums to the request.
1. [x] Upload final RPM & DEB packages to cloudsmith.io
1. Go to [release-pkgs-upload-internal](https://jenkins.isc.org/job/kea-dev/job/release-pkgs-upload-internal/).
1. Click "Build with Parameters" link
1. Pick your selected pkg build in Packages field, and select `PrivPubRepos: "both"`, `TestProdRepos: "production"` and click Build button.
1. When it finishes run check: [releases-pkgs-check-internal](https://jenkins.isc.org/job/kea-dev/job/release-pkgs-check-internal/).
1. [x] Create git tags `Kea-a.b.c` in Kea main and premium repositories.
1. Update ReadTheDocs
1. [x] Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. [x] Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. [x] For stable releases, change the default version to point to this stable release.
### On the Day of Public Release
- [ ] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *kea-announce*.
- [ ] ***(Support)*** Write email to *kea-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [ ] ***(Support)*** If it is a new major version, sweng will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Then update support customers that this new private repo exists.
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(Marketing)*** Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version.
- [x] ***(Marketing)*** Announce on social media.
- [x] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(Marketing)*** Update [Kea page on web site if any new hooks](https://www.isc.org/kea/).
- [x] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [x] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
- [x] ***(Marketing)*** Update [Kea documentation page in KB](https://kb.isc.org/docs/en/kea-administrator-reference-manual).
## Post-Release, But Before Code Unfreeze
- [x] Bump up Kea version in `configure.ac` to next development version which could be, based on just released version `a.b.c`:
* `a.b.z-git` where `z == c + 1` or
* `a.y.0-git` where `y == b + 1` or
* `x.1.0-git` where `x == a + 1`
- [x] Bump up `REF_KEA_VERSION` in `qa-dhcp/kea/jenkins/tarball-internal.jenkinsfile` to `x.y.z` i.e. released versionkea1.9.6Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1767check static analysers reports2022-11-02T15:10:18ZWlodzimierz Wencelcheck static analysers reportsRecent increased interest in security reminded me that it was some time since anyone looked into our static analysers, reports are:
* https://scan.coverity.com/projects/kea/view_defects (if you don't have an account please sign in and re...Recent increased interest in security reminded me that it was some time since anyone looked into our static analysers, reports are:
* https://scan.coverity.com/projects/kea/view_defects (if you don't have an account please sign in and request access to kea)
* https://jenkins.isc.org/view/All/job/kea-master-cppcheck-internal/
We need:
* review reports
* in coverity mark issues with correct status
* open tickets for real issues
* fix issues :)backlogRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1747systemd support files provided with ISC Kea packages reference wrong service ...2021-05-06T04:36:23ZMichael McNallysystemd support files provided with ISC Kea packages reference wrong service names (Kea 1.8.2)[A support customer reports](https://support.isc.org/Ticket/Display.html?id=18102) that, due to an error in the files provided to support use with systemd, a couple of the Kea services do not properly restart when using ISC-provided pack...[A support customer reports](https://support.isc.org/Ticket/Display.html?id=18102) that, due to an error in the files provided to support use with systemd, a couple of the Kea services do not properly restart when using ISC-provided packages on systems that use systemd.
From the support ticket:
>>>
Hello ISC,
I've just installed two brand new servers with kea 1.8.2 and enabled the kea-ctrl-agent, and kea-dhcp4 services via aystemd.
But it's only kea-dhcp4 that starts..
I think this is caused by some mispelling in the systemd unit files.
cat /lib/systemd/system/kea-ctrl-agent.service
```
...
[Install]
WantedBy=kea-dhcp4-server.service
WantedBy=kea-dhcp6-server.service
WantedBy=kea-dhcp-ddns.service
```
The kea-dhcp4-server and kea-dhcp6-server services don't exists.. - But if I change the values to:
```
[Install]
WantedBy=kea-dhcp4.service
WantedBy=kea-dhcp6.service
WantedBy=kea-dhcp-ddns.service
```
It works very well..
>>>
They are using:
- Kea 1.8.2
- Centos 7kea1.8.3Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/1702Fix gtest cp -p flag2021-03-25T18:53:31ZTomek MrugalskiFix gtest cp -p flagAs reported by @manu:
```
why you enforce -p flag for 'cp' ?
https://gitlab.isc.org/isc-projects/kea/-/blob/master/ext/gtest/Makefile.am#L10
it would be good idea to remove it as it causes errors
cp -p /usr/src/googletest/googletest//s...As reported by @manu:
```
why you enforce -p flag for 'cp' ?
https://gitlab.isc.org/isc-projects/kea/-/blob/master/ext/gtest/Makefile.am#L10
it would be good idea to remove it as it causes errors
cp -p /usr/src/googletest/googletest//src/gtest-all.cc gtest-all.cc
cp: can't preserve ownership of 'gtest-all.cc': Operation not permitted
as we copy file owned by root to jenkins's workspace under jenkins user. The file is copied anyway but without preserved ownership which we don't need, right? So the -p flag is not required from my point of view.
```kea1.9.5Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1696Bad links on HA design like page2021-03-12T06:56:36ZPeter DaviesBad links on HA design like pageThe links to diagrams and external sites appear to be broken in the HA design document in the GitHub wiki at:
https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/High-Availability-Design
https://gitlab.isc.org/isc-projects/kea/-/...The links to diagrams and external sites appear to be broken in the HA design document in the GitHub wiki at:
https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/High-Availability-Design
https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/high%20availability%20design
Error 404
https://gitlab.isc.org/uploads/0a74fa580fe370d855e58ca1ecdea8ab/Hot-standby.svg
https://gitlab.isc.org/uploads/eae92b691bd119d4017e425f6b63546e/multi-site.svg
https://gitlab.isc.org/uploads/42ea673115e87a10414c921f9e70e20b/standby-backup.svg
https://gitlab.isc.org/uploads/ed433e632b1549cf45d8eae541d3b22f/multiple-backup.svg
https://gitlab.isc.org/uploads/56fd394ac3b5bcadd3fc1c9a50a0c917/Load-balancing.svg
https://gitlab.isc.org/uploads/2734adbaf46f93445d62e7935c36d6b1/sql-replication.svg
https://gitlab.isc.org/uploads/2ea15c5bfba9b6c9759cf42743c835f8/kea-ha-communication-diagram.svg
https://gitlab.isc.org/uploads/6d5d6dfcfa8c58a75bde42d295db84cb/ha-failure-detection.svg
https://gitlab.isc.org/uploads/b0fe516311f0adc3fcadb5256ba4aa3f/ha-server-startup-state.svg
https://gitlab.isc.org/uploads/939266b71468008cb1001843b04b5181/kea-ha-sequence-diagram.svg
https://gitlab.isc.org/uploads/333eb3c9faae1a751a431e280426b898/ha-simultanous-updates-sequence-diagram.svg
https://gitlab.isc.org/uploads/353ff231d9303d0671d7e18d4dde2e0b/ha-testing-env.svg
link leads to "create new page".
https://gitlab.isc.org/isc-projects/kea/-/wikis/RFC3074 - "link to create new page"
https://gitlab.isc.org/isc-projects/kea/-/wikis/w3.org -> link to create new page"kea1.9.6Marcin SiodelskiMarcin Siodelski