Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-02-20T18:22:47Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3231PerfMon-Core-Task-3 Modify Dhcpv4Srv and Dhcpv6Srv to add packet events2024-02-20T18:22:47ZThomas MarkwalderPerfMon-Core-Task-3 Modify Dhcpv4Srv and Dhcpv6Srv to add packet eventsComplete Kea Core task 3 per PerfMon design: https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/performance-monitor#kea-core-tasksComplete Kea Core task 3 per PerfMon design: https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/performance-monitor#kea-core-taskskea2.5.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/3238Sanity checks for Kea 2.5.5 rc12024-02-20T10:26:54ZWlodzimierz WencelSanity checks for Kea 2.5.5 rc1We are now at step SANITY CHECKS of Kea 2.5.5 rc1.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-co...We are now at step SANITY CHECKS of Kea 2.5.5 rc1.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks) and according to your imagination.
Before starting, please state what you are checking in a thread/discussion (not as comment).
When you finish a check, state in the same thread/discussion what the result is.
This way we know what is covered upfront and we can avoid repeating ourselves.
#### Tarballs on repo.isc.org
* `/data/shared/sweng/kea/releases/2.5.5-rc1`
* `/data/shared/sweng/kea/releases/premium-2.5.5-rc1`
* `/data/shared/sweng/kea/releases/subscription-2.5.5-rc1`
* `/data/shared/sweng/kea/releases/enterprise-2.5.5-rc1`
```
SHA256 (kea-2.5.5.tar.gz) = 77918ea7ccb9bc89756c3e52a26adf515b91e47dbf258027fa973f68eff82f67
SHA256 (kea-enterprise-2.5.5.tar.gz) = 8041d0fd418846c36dc51dc0b64cb820ba46c5d1ec392990f2d30068272c3013
SHA256 (kea-premium-2.5.5.tar.gz) = b376b98480dcf31435d72f42edfc194ba41c3864dacd12fd3d46f43f5ae9d6c4
SHA256 (kea-subscription-2.5.5.tar.gz) = ae4b940a984d80fa93d0f9130bb1fdf41c15cf29858a46dbbf8a5eda98119768
```
#### Packages on packages.aws.isc.org
* [APK: 2.5.5-r20240129145054](https://packages.aws.isc.org/#browse/search/raw=format%3Draw%20AND%20name.raw%3D*r20240129145054.apk)
* [deb: 2.5.5-isc20240129145054](https://packages.aws.isc.org/#browse/search/apt=format%3Dapt%20AND%20version%3D2.5.5-isc20240129145054)
* [RPM: 2.5.5-isc20240129145054.\[os\]](https://packages.aws.isc.org/#browse/search/yum=format%3Dyum%20AND%20version%3D2.5.5-isc20240129145054*)
You can find the name for all the packages attached as build artifacts in the pkg job: https://jenkins.aws.isc.org/job/kea-dev/job/pkg/1407/
Instructions for installing packages are at point 9 of [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks).kea2.5.6Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/3242PerfMon-Hook-Task-1 Implement skeleton of new hook library2024-02-16T17:58:36ZThomas MarkwalderPerfMon-Hook-Task-1 Implement skeleton of new hook libraryCreate the necessary core hook sub directories and basic infrastructure. The skeleton hook should load and unload and provide empty C callout functions.Create the necessary core hook sub directories and basic infrastructure. The skeleton hook should load and unload and provide empty C callout functions.kea2.5.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/3230PerfMon-Core-Tasks-1-and-2 Create PktEvent Class Modify PktFilters2024-02-16T16:58:12ZThomas MarkwalderPerfMon-Core-Tasks-1-and-2 Create PktEvent Class Modify PktFiltersComplete Kea Core tasks 1 and 2 per PerfMon design: https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/performance-monitor#kea-core-tasksComplete Kea Core tasks 1 and 2 per PerfMon design: https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/performance-monitor#kea-core-taskskea2.5.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1Update NETCONF requirements and design2024-02-16T13:28:24ZTomek MrugalskiUpdate NETCONF requirements and designAs the first step, we need to expand [the requirements](../wikis/designs/netconf-requirements) and [the design](../wikis/designs/netconf-design) pages. These are living documents, so they probably will never be truly done.
Nevertheless,...As the first step, we need to expand [the requirements](../wikis/designs/netconf-requirements) and [the design](../wikis/designs/netconf-design) pages. These are living documents, so they probably will never be truly done.
Nevertheless, the goal of this ticket is to have them sufficiently complete, so the code implementation could start and there's realistic expectation that other parties interested in the code (QA team, external users) could have realistic expectation what they would get.Kea1.5-beta1Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/31722.5.4 release checklist2024-02-16T13:00:00ZAndrei Pavelandrei@isc.org2.5.4 release checklist---
name: a.b.c 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/KeaRelease...---
name: a.b.c 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 these checks and updates can be made before the actual freeze. For new stable releases or maintenance releases, please don't use the `kea-dev` build farm; use a dedicated build farm for each release cycle.
1. [x] 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/build-tarball/Kea_20Build_20Checks/)
1. [ ] Check [Performance Test Results](https://jenkins.aws.isc.org/job/kea-dev/job/performance/lastSuccessfulBuild/artifact/qa-dhcp/kea/performance-jenkins/report.html) in Jenkins for drops in performance.
1. [x] Create a Gitlab issue for bumping up library versions and `KEA_HOOKS_VERSION` and notify developers.
* In case of no developers available, it can be done by running: [./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. [ ] Look at the issue numbers in commit descriptions. Add to ChangeLog a mention about any change with visible impact that had not been mentioned already.
1. [ ] If any changes have been done to database schemas, then:
1. [ ] Check that a previously released schema has not been changed.
1. [ ] Check that the additions to `dhcpdb_create.*sql`, and nothing more nor less than what was added in this release, is present in a `upgrade_*_to_*.sh.in` script that should also have been added in this release.
1. [x] Prepare release notes.
1. [x] Create release note on Kea GitLab wiki and notify @tomek. It should be created under the `Release-Notes` directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/Release-Notes/release-notes-2.3.4
1. [ ] Finish release notes and conduct its review.
1. [ ] Notify support that release notes are ready for review. To avoid conflicts in edits wait with next step after review is done.
1. [ ] Notify @sgoldlust or @vicky that release notes are ready for review. Due to time difference please do this at least 36 hours before planned release.
1. [x] Check that packages can be uploaded to cloudsmith.
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick the latest pkg build in the `Packages` field, and the corresponding tarball build in the `Tarball` field, leave the rest as they are `PrivPubRepos: "private"`, `TarballOrPkg: "packages"`, `TestProdRepos: "testing"` and click `Build`.
1. If a new Cloudsmith repository is used, then:
1. [ ] Make sure freeradius packages are uploaded to the Cloudsmith repository or copied from a previous repository.
1. [ ] Make sure access tokens have 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. Alternatively, look for failures in emails if you know that the ReadTheDocs webhook is working.
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) \
Example command: `GITLAB_TOKEN='...' ./update-code-for-release.py 2.3.4 --repo-dir ~/isc/repos/kea/`. \
Help: `GITLAB_TOKEN='...' ./update-code-for-release.py --help`. \
The script requires an explicit flag for stable and maintenances releases e.g. `--repo-branch v2_4`. \
The script makes the following changes and actions:
1. Runs [prepare_kea_release.sh](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/prepare_kea_release.sh) that:
1. Adds release entries in ChangeLogs.
1. Updates Kea version in configure.ac.
1. Updates copyright years in files that were changed in current year.
1. Sorts message files.
1. Regenerates message files headers.
1. Regenerates parsers using Bison from Docker
1. [x] Run the script again with the `--upload-only` flag which:
1. Creates an issue in GitLab for release changes in kea repo.
1. Creates branches and merge requests for kea and kea-premium.
1. Commits the changes in both repos.
1. Checks out created branches in both repos.
1. Commits and pushes the changes to GitLab server.
1. [x] Check manually User's Guide sections:
1. [ ] Chapter 1. Introduction
1. [ ] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [ ] Did we add any additional 3rd party software? Update if needed.
1. [ ] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. [ ] Chapter 2. Quick Start
1. [ ] 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. [ ] 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. [ ] Check and update Build Requirements.
1. [ ] 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 [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/) 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 each of the installed binaries has a man page.
1. If not, is the binary included in the tarball? That might explain it.
1. Are man pages 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](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
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. Submit the job that will automatically:
1. Upload the tarballs.
1. Create a GitLab issue for sanity checks, put the announcement there.
1. Send Sanity Checks announcement on the Kea/DHCP channel on Mattermost.\
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
Now it's time to publish the code.
1. [x] Update Release Notes with ChangeLog entries.
1. [x] Mark Jenkins jobs with release artifacts to be kept forever and update description of build by adding there version of released kea (e.g. `Kea-2.3.4`).
1. Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button and edit description:
1. [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/).
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/).
1. [x] Upload final tarballs to repo.isc.org.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
1. In field `Release_Candidate` pick `final`. This job will also:
- Open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) for signing final tarballs on repo.isc.org.
- Create Git tags `Kea-a.b.c` in Kea main and premium repositories.
- Create Gitlab releases `Kea-a.b.c` in Kea main and premium repositories.
1. [x] Sign tarballs with the personal key, by running [sign_kea_and_upload_asc.sh](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/sign_kea_and_upload_asc.sh) which signs, verifies signatures and uploads them.
- If release engineer does NOT have signing key, please contact team member.
1. [x] Confirm that the tarballs have the checksums mentioned on the signing ticket.
1. [ ] Wait for clearance from Security Officer to proceed with the public release (if applicable). If this is a security release, next steps will be impacted by CVE checklist.
1. [x] Login to repo.isc.org and upload final tarball to public ftp using make-available script (only OPS can remove incorrectly uploaded tarballs).
* [x] For premium tarballs use `--private` option.
* For newest stable release use `--symlink=cur` option.
* Example command: `make-available --public --symlink=cur /data/shared/sweng/kea/releases/2.3.4`.
* [x] save links to all premium tarballs and put them into signing ticket as a comment.
1. [x] Upload final RPM & DEB packages, tarballs and sign files to cloudsmith.io:
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick your selected pkg build in the `Packages` field, the corresponding tarball build in the `Tarball` field, `PrivPubRepos: "both"`, `TarballOrPkg: "both"`, `TestProdRepos: "production"` and click `Build`.
- This step also verifies sign files.
1. When it finishes run check: [releases-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/).
1. [ ] Check that Docker images can be uploaded to Cloudsmith. Run [build-upload-docker](https://jenkins.aws.isc.org/job/kea-dev/job/build-upload-docker/).
* Make sure the right package job is selected under `Packages`.
* Tick `Upload`.
* Leave `TestProdRepos` to `testing`.
* Leave `versionTag` ticked.
* Tick `latestTag` if this is a stable or a maintenance release.
* If this is a stable or maintenance release, change `KeaDockerBranch` to the appropriate branch.
* Press `Build`.
1. [x] Build and upload Docker images to Cloudsmith. Run [build-upload-docker](https://jenkins.aws.isc.org/job/kea-dev/job/build-upload-docker/) with the same actions as above except change `TestProdRepos` to `production`.
1. [x] Update ReadTheDocs:
1. Trick ReadTheDocs into pulling the latest tags. Click `Build version` 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. If it's a stable release, change the default version to point to this stable release. `Admin -> Advanced Settings -> Default version* -> Kea-a.b.c`.
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` most of the time, or
* `a.y.0-git` where `y == b + 2` if a new development series starts, or
* `x.1.0-git` where `x == a + 1` when the released minor version `b` is 9 and `a.b.c` was the last version in the development series and a new development version is coming up next.
1. [x] Contact Marketing team, and find a member who will continue work on this release:
1. [x] Assign this ticket to person who will continue.
1. [x] Share link to signing ticket either directly or as a comment in this issue.
## Marketing
1. [x] Publish links to downloads on ISC website.
1. [x] Update the supported versions document in the Salesforce portal (if there are stable versions released), and update the Kea document in the portal.
1. [x] 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. Verify that the KB on installing from Cloudsmith has also been updated, then update the Kea document in the SF portal and notify support customers that this new private repo exists.
1. [x] If a new Cloudsmith repository is used, make sure that the Zapier scripts are updated.
* If those are not updated, there was an error made during preparation for new stable release. Please contact QA team and coordinate fix.
1. [x] 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.
1. [x] Write release email to _kea-announce_.
1. [ ] Write email to _kea-users_ (if a major release).
1. [x] Announce on social media.
1. [x] Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea\_(software)).
1. [ ] Write blog article (if a major release).
1. [x] Update [Kea page on website if any new hooks](https://www.isc.org/kea/).
1. [ ] Update Kea Premium and Kea Subscription data sheets if any new hooks.
1. [x] Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
1. [x] Contact Support team, find a person who will continue this release and assign this issue to them.
## Support
1. [x] Update tickets in case of waiting for support customers.
1. [x] Close this ticketkea2.5.4Darren AnkneyDarren Ankney2023-11-29https://gitlab.isc.org/isc-projects/kea/-/issues/3243Associate option 43, code 1 with a client class using Postgres2024-02-13T06:33:50ZAlessandro SagratiniAssociate option 43, code 1 with a client class using PostgresHi all, I am setting up ubnt.unifi-address vendor-specific option with Postgres; everything works as expected if the configuratiion is "hardcoded" in the configuration file, like here:
```plaintext
"option-def": [
{
...Hi all, I am setting up ubnt.unifi-address vendor-specific option with Postgres; everything works as expected if the configuratiion is "hardcoded" in the configuration file, like here:
```plaintext
"option-def": [
{
"name": "unifi-address",
"code": 1,
"space": "ubnt",
"type": "ipv4-address",
"array": false
}
],
"client-classes": [
{
"name": "ubnt",
"test": "option[vendor-class-identifier].text == 'ubnt'",
"option-def": [
{
"name": "vendor-encapsulated-options",
"code": 43,
"space": "dhcp4",
"type": "empty",
"encapsulate": "ubnt"
}
],
"option-data": [
{
"name": "unifi-address",
"space": "ubnt",
"data": "123.123.123.123"
},
{
"name": "vendor-encapsulated-options"
}
]
}
],
```
Additionally, if I have this configuration in the database the option is also sent, but it's sent regardless if the client matches the client-class:
```plaintext
keadb=# select * from dhcp4_option_def;
id | code | name | space | type | modification_ts | is_array | encapsulate | record_types | user_context | class_id
----+------+-----------------------------+-------+------+-------------------------------+----------+-------------+--------------+--------------+----------
3 | 1 | unifi-address | ubnt | 10 | 2024-02-06 09:35:01.055685+00 | f | | | |
4 | 43 | vendor-encapsulated-options | dhcp4 | 0 | 2024-02-07 08:47:48.873602+00 | f | ubnt | | |
(2 rows)
keadb=# select * from dhcp4_option_def_server;
option_def_id | server_id | modification_ts
---------------+-----------+-------------------------------
3 | 1 | 2024-02-06 10:18:21.478424+00
4 | 1 | 2024-02-07 08:48:25.798256+00
keadb=# select * from dhcp4_options;
option_id | code | value | formatted_value | space | persistent | dhcp_client_class | dhcp4_subnet_id | host_id | scope_id | user_context | shared_network_name | pool_id | modification_ts | cancelled
-----------+------+-------+-------------------------------------+-------+------------+-------------------+-----------------+---------+----------+--------------+---------------------+---------+-------------------------------+-----------
...
1 | 43 | | | dhcp4 | f | | | | 0 | | | | 2024-02-06 10:14:53.913124+00 | f
27 | 1 | | 123.123.123.123 | ubnt | f | | | | 0 | | | | 2024-02-04 09:58:52.903827+00 | f
...
(23 rows)
keadb=# select * from dhcp4_options_server;
option_id | server_id | modification_ts
-----------+-----------+-------------------------------
27 | 1 | 2024-02-06 10:29:05.870566+00
1 | 1 | 2024-02-07 08:49:19.538328+00
(2 rows)
```
* client class is defined as:
```plaintext
keadb=# select * from dhcp4_client_class;
id | name | test | next_server | server_hostname | boot_file_name | only_if_required | valid_lifetime | min_valid_lifetime | max_valid_lifetime | depend_on_known_directly | follow_class_name | modification_ts | user_context | offer_lifetime
----+------+------------------------------------------------+-------------+-----------------+----------------+------------------+----------------+--------------------+--------------------+--------------------------+-------------------+-------------------------------+--------------+----------------
8 | ubnt | option[vendor-class-identifier].text == 'ubnt' | | | | t | | | | f | | 2024-02-04 10:14:23.624558+00 |
```
I know I have to change dhcp_client_class, scope_id in dhcp4_options table and class_id in dhcp4_option_def, but I wonder if there's more than that to associate the options to the class, so they match the "hardcoded" configuration snippet I posted?
Let me know if you need anything else from me. Thank yououtstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3119Coverity scan issues2024-02-06T12:55:09ZPiotrek ZadrogaCoverity scan issuesI triaged new issues detected by Coverity scan and below ones could be checked more carefully:
- High: `time_t` casting to `uint_32` - assuming we are doing `static_cast`, we should be ok until year 2106. One cases misses the `static_ca...I triaged new issues detected by Coverity scan and below ones could be checked more carefully:
- High: `time_t` casting to `uint_32` - assuming we are doing `static_cast`, we should be ok until year 2106. One cases misses the `static_cast`.
- https://scan5.scan.coverity.com/reports.htm#v60426/p10289/fileInstanceId=250303669&defectInstanceId=53277773&mergedDefectId=1533185
- Medium: dereferencing invalid iterator - in most cases it seems to be false positive, but there is one place where it could be checked - this could have separate ticket
- https://scan5.scan.coverity.com/reports.htm#v60426/p10289/fileInstanceId=250303968&defectInstanceId=53270168&mergedDefectId=1533337
- Low: used `auto` causing copy - this is low priority, but could be fixed anyway, just `const auto&` could be used.
- https://scan5.scan.coverity.com/reports.htm#v60426/p10289/fileInstanceId=250303713&defectInstanceId=53363199&mergedDefectId=1539484
- https://scan5.scan.coverity.com/reports.htm#v60426/p10289/fileInstanceId=250303704&defectInstanceId=53363142&mergedDefectId=1539483
- https://scan5.scan.coverity.com/reports.htm#v60426/p10289/fileInstanceId=250303706&defectInstanceId=53363182&mergedDefectId=1539482
- https://scan5.scan.coverity.com/reports.htm#v60426/p10289/fileInstanceId=250304018&defectInstanceId=53270328&mergedDefectId=1532980 and all others in `src/hooks/dhcp/lease_cmds/lease_cmds.cc`
- https://scan5.scan.coverity.com/reports.htm#v60426/p10289/fileInstanceId=250304037&defectInstanceId=53270311&mergedDefectId=1532961 and all others in `src/hooks/dhcp/mysql_cb/mysql_cb_dhcp*.cc`
- https://scan5.scan.coverity.com/reports.htm#v60426/p10289/fileInstanceId=250304057&defectInstanceId=53270884&mergedDefectId=1532978 and all others in `src/hooks/dhcp/pgsql_cb/pgsql_cb_dhcp*.cc`kea2.5.5Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/32362.5.5 release checklist2024-01-31T19:24:29ZWlodzimierz Wencel2.5.5 release checklist# 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 these checks and updates can be made before the actual fr...# 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 these checks and updates can be made before the actual freeze. For new stable releases or maintenance releases, please don't use the `kea-dev` build farm; use a dedicated build farm for each release cycle.
1. [x] 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/build-tarball/Kea_20Build_20Checks/)
1. [x] Check [Performance Test Results](https://jenkins.aws.isc.org/job/kea-dev/job/performance/lastSuccessfulBuild/artifact/qa-dhcp/kea/performance-jenkins/report.html) in Jenkins for drops in performance.
1. [x] Create a Gitlab issue for bumping up library versions and `KEA_HOOKS_VERSION` and notify developers.
* In case of no developers available, it can be done by running: [./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. [x] Look at the issue numbers in commit descriptions. Add to ChangeLog a mention about any change with visible impact that had not been mentioned already.
1. [x] If any changes have been done to database schemas, then:
1. [x] Check that a previously released schema has not been changed.
1. [x] Check that the additions to `dhcpdb_create.*sql`, and nothing more nor less than what was added in this release, is present in a `upgrade_*_to_*.sh.in` script that should also have been added in this release.
1. [x] Prepare release notes.
1. [x] Create release note on Kea GitLab wiki and notify @tomek. It should be created under the `Release-Notes` directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/Release-Notes/release-notes-2.3.4
1. [x] Finish release notes and conduct its review.
1. [x] Notify support that release notes are ready for review. To avoid conflicts in edits wait with next step after review is done.
1. [x] Notify @sgoldlust or @vicky that release notes are ready for review. Due to time difference please do this at least 36 hours before planned release.
1. [ ] Check that packages can be uploaded to cloudsmith.
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick the latest pkg build in the `Packages` field, and the corresponding tarball build in the `Tarball` field, leave the rest as they are `PrivPubRepos: "private"`, `TarballOrPkg: "packages"`, `TestProdRepos: "testing"` and click `Build`.
1. If a new Cloudsmith repository is used, then:
1. [ ] Make sure access tokens have 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. Alternatively, look for failures in emails if you know that the ReadTheDocs webhook is working.
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) \
Example command: `GITLAB_TOKEN='...' ./update-code-for-release.py 2.3.4 --repo-dir ~/isc/repos/kea/`. \
Help: `GITLAB_TOKEN='...' ./update-code-for-release.py --help`. \
The script requires an explicit flag for stable and maintenances releases e.g. `--repo-branch v2_4`. \
The script makes the following changes and actions:
1. Runs [prepare_kea_release.sh](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/prepare_kea_release.sh) that:
1. Adds release entries in ChangeLogs.
1. Updates Kea version in configure.ac.
1. Updates copyright years in files that were changed in current year.
1. Sorts message files.
1. Regenerates message files headers.
1. Regenerates parsers using Bison from Docker
1. [x] Run the script again with the `--upload-only` flag which:
1. Creates an issue in GitLab for release changes in kea repo.
1. Creates branches and merge requests for kea and kea-premium.
1. Commits the changes in both repos.
1. Checks out created branches in both repos.
1. Commits and pushes the changes to GitLab server.
1. [x] Check manually User's Guide sections:
1. [x] 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. [x] 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. [x] 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 [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/) 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 each of the installed binaries has a man page.
1. If not, is the binary included in the tarball? That might explain it.
1. Are man pages 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](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
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. Submit the job that will automatically:
1. Upload the tarballs.
1. Create a GitLab issue for sanity checks, put the announcement there.
1. Send Sanity Checks announcement on the Kea/DHCP channel on Mattermost.\
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
Now it's time to publish the code.
1. [x] Update Release Notes with ChangeLog entries.
1. [x] Mark Jenkins jobs with release artifacts to be kept forever and update description of build by adding there version of released kea (e.g. `Kea-2.3.4`).
1. Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button and edit description:
1. [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/).
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/).
1. [x] Upload final tarballs to repo.isc.org.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
1. In field `Release_Candidate` pick `final`. This job will also:
- Open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) for signing final tarballs on repo.isc.org.
- Create Git tags `Kea-a.b.c` in Kea main and premium repositories.
- Create Gitlab releases `Kea-a.b.c` in Kea main and premium repositories.
1. [x] Sign tarballs with the personal key, by running [sign_kea_and_upload_asc.sh](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/sign_kea_and_upload_asc.sh) which signs, verifies signatures and uploads them.
- If release engineer does NOT have signing key, please contact team member.
1. [x] Confirm that the tarballs have the checksums mentioned on the signing ticket.
1. [ ] Wait for clearance from Security Officer to proceed with the public release (if applicable). If this is a security release, next steps will be impacted by CVE checklist.
1. [x] Login to repo.isc.org and upload final tarball to public ftp using the make-available script.
* Example command: `make-available --public --symlink=cur/2.3 /data/shared/sweng/kea/releases/2.3.4`.
* [x] For premium tarballs use `--private` option.
* For more information use `--debug` option.
* To overwrite existing content, use `--force` option.
* If you did a mistake, contact ASAP someone from the ops team to remove incorrectly uploaded tarballs.
* [x] save links to all premium tarballs and put them into signing ticket as a comment.
1. [x] Upload final RPM & DEB packages, tarballs and sign files to cloudsmith.io:
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick your selected pkg build in the `Packages` field, the corresponding tarball build in the `Tarball` field, `PrivPubRepos: "both"`, `TarballOrPkg: "both"`, `TestProdRepos: "production"` and click `Build`.
- This step also verifies sign files.
1. When it finishes run check: [releases-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/).
1. [ ] Check that Docker images can be uploaded to Cloudsmith. Run [build-upload-docker](https://jenkins.aws.isc.org/job/kea-dev/job/build-upload-docker/).
* Make sure the right package job is selected under `Packages`.
* Tick `Upload`.
* Leave `TestProdRepos` to `testing`.
* Leave `versionTag` ticked.
* Tick `latestTag` if this is a stable or a maintenance release.
* If this is a stable or maintenance release, change `KeaDockerBranch` to the appropriate branch.
* Press `Build`.
1. [x] Build and upload Docker images to Cloudsmith. Run [build-upload-docker](https://jenkins.aws.isc.org/job/kea-dev/job/build-upload-docker/) with the same actions as above except change `TestProdRepos` to `production`.
1. [x] Update ReadTheDocs:
1. Trick ReadTheDocs into pulling the latest tags. Click `Build version` 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. If it's a stable release, change the default version to point to this stable release. `Admin -> Advanced Settings -> Default version* -> Kea-a.b.c`.
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` most of the time, or
* `a.y.0-git` where `y == b + 2` if a new development series starts, or
* `x.1.0-git` where `x == a + 1` when the released minor version `b` is 9 and `a.b.c` was the last version in the development series and a new development version is coming up next.
1. [x] Contact Marketing team, and find a member who will continue work on this release:
1. [x] Assign this ticket to person who will continue.
1. [x] Share link to signing ticket either directly or as a comment in this issue.
## Marketing
1. [x] Publish links to downloads on ISC website.
1. [x] Update the supported versions document in the Salesforce portal (if there are stable versions released), and update the Kea document in the portal.
1. [x] 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. Verify that the KB on installing from Cloudsmith has also been updated, then update the Kea document in the SF portal and notify support customers that this new private repo exists.
1. [x] If a new Cloudsmith repository is used, make sure that the Zapier scripts are updated.
* If those are not updated, there was an error made during preparation for new stable release. Please contact QA team and coordinate fix.
1. [x] 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.
1. [x] Write release email to _kea-announce_.
1. [x] Write email to _kea-users_ (if a major release).
1. [ ] Announce on social media.
1. [x] Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea\_(software)).
1. [x] Write blog article (if a major release).
1. [x] Update [Kea page on website if any new hooks](https://www.isc.org/kea/).
1. [x] Update Kea Premium and Kea Subscription data sheets if any new hooks.
1. [ ] Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
1. [x] Contact Support team, find a person who will continue this release and assign this issue to them.
## Support
1. [x] Update tickets in case of waiting for support customers.
1. [x] Close this ticketkea2.5.5https://gitlab.isc.org/isc-projects/kea/-/issues/3240bump up version in configure.ac to 2.5.6-git2024-01-31T11:46:31ZWlodzimierz Wencelbump up version in configure.ac to 2.5.6-gitkea2.5.6Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/3234Update Kea Premium License text2024-01-29T14:40:19ZVicky Riskvicky@isc.orgUpdate Kea Premium License textThe Kea Premium license text has been updated to version 2.1.1. I made a MR over in the Premium repo but I don't know how to tell for sure if the license text has to go in headers for multiple files, or just in the 'copying' file at the ...The Kea Premium license text has been updated to version 2.1.1. I made a MR over in the Premium repo but I don't know how to tell for sure if the license text has to go in headers for multiple files, or just in the 'copying' file at the top of the tree.kea2.5.5https://gitlab.isc.org/isc-projects/kea/-/issues/3237Changes for Kea 2.5.5 release2024-01-29T14:39:11ZWlodzimierz WencelChanges for Kea 2.5.5 release
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright years
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright yearskea2.5.5Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/2788Kea might not use getopt correctly on alpine2024-01-26T18:01:50ZAndrei Pavelandrei@isc.orgKea might not use getopt correctly on alpineOn all the alpine systems in jenkins, we have this failure:
```
netconf_controller_unittests.cc:134
Expected equality of these values:
std::string(ex.what())
Which is: "unsupported option: [x] d2-test-config.json"
"unsupported o...On all the alpine systems in jenkins, we have this failure:
```
netconf_controller_unittests.cc:134
Expected equality of these values:
std::string(ex.what())
Which is: "unsupported option: [x] d2-test-config.json"
"unsupported option: [x] "
```
It's not related only to NETCONF. The tests there are just more thorough and check for the error message and that's why it appears only there. The tested code is common to all binaries.
The tested argument is just `-x`. It could be that on alpine systems, the way Kea uses getopt in `DControllerBase::parseArgs()` doesn't clear an argument previously used in the same unit test, which would be why `d2-test-config.json` appears in the error message.
You can see the failures here: https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/1017/.kea2.5.5Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3235bump up lib versions for 2.5.52024-01-26T17:03:30ZWlodzimierz Wencelbump up lib versions for 2.5.5as stated in the subject ;)as stated in the subject ;)kea2.5.5Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/3123Synced leases with HA standby cause RADIUS accounting packets2024-01-26T15:38:09ZDarren AnkneySynced leases with HA standby cause RADIUS accounting packetsIf the Kea HA peers (`libdhcp_ha.so`) are configured to send RADIUS accounting packets using the `libdhcp_radius.so` hook, then the standby peer also sends accounting packets on lease sync. This can create a few problems such as:
- The ...If the Kea HA peers (`libdhcp_ha.so`) are configured to send RADIUS accounting packets using the `libdhcp_radius.so` hook, then the standby peer also sends accounting packets on lease sync. This can create a few problems such as:
- The "acct-session-id" will not match between the accounting packets sent from the primary and standby Kea peers.
- The timestamp of the event may not match between the packets sent from the primary and standby Kea peers.
- If there were attributes gathered via the RADIUS authentication process, this will not have occurred on the standy peer. Therefore, there may be missing data in the accounting packet.
Propose that some type of flag to disable sending these accounting updates from the standby server be added.
[SF1403](https://isc.lightning.force.com/lightning/r/Case/5007V00002ZRLi2QAH/view)kea2.5.5Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3178Run multiple HA relationships in hub-and-spoke configuration2024-01-26T14:35:10ZMarcin SiodelskiRun multiple HA relationships in hub-and-spoke configurationThis is the actual implementation of the hub-and-spoke model described in the design ticket: https://gitlab.isc.org/isc-projects/kea/-/issues/1149
It should add the logic to run multiple `HAService` instances concurrently. The major iss...This is the actual implementation of the hub-and-spoke model described in the design ticket: https://gitlab.isc.org/isc-projects/kea/-/issues/1149
It should add the logic to run multiple `HAService` instances concurrently. The major issue is to implement the callouts for the `subnet4_select` and `subnet6_select` hook points that would be used in the hub-and-spoke configuration to select the relationship based on the selected subnet. We should also test that the `HAService` instances do not stomp on each other, that are thread safe etc. After this ticket, the hub-and-spoke configuration should be usable, at least in a basic form.
[support#22017](https://support.isc.org/Ticket/Display.html?id=22017).kea2.5.5Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1149Extend Kea HA to permit a single backup server for multiple primary/active se...2024-01-26T14:35:10ZVicky Riskvicky@isc.orgExtend Kea HA to permit a single backup server for multiple primary/active serversAs an administrator with many offices, each with a local Kea server, I would prefer to have a single backup server, centrally located, that can serve as backup for many remote Kea servers.
I realize that one option is to run multiple Ke...As an administrator with many offices, each with a local Kea server, I would prefer to have a single backup server, centrally located, that can serve as backup for many remote Kea servers.
I realize that one option is to run multiple Kea servers on the single machine at HQ, but monitoring and managing that single Kea server would also present scaling issues. This request is to be able to have a single Kea server that has multiple failover relationships.
* The scale would be dozens of remote active nodes to a single passive node.
* In this scenario, the active Kea servers are not likely to be heavily loaded or extremely active.
* It is ok if the central server is limited in the number of relationships in which it can become the primary simultaneously.kea2.5.5https://gitlab.isc.org/isc-projects/kea/-/issues/1790[ISC-support #18162] Configuration Backend and map parameters2024-01-26T13:50:32ZBertrand Buclin[ISC-support #18162] Configuration Backend and map parameters---
name: Feature request
about: Configuration backend and map parameters
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? yes
- Are you sure what you would like to do is ...---
name: Feature request
about: Configuration backend and map parameters
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? yes
- Are you sure what you would like to do is not possible using some other mechanisms? yes
- Have you discussed your idea on kea-users or kea-dev mailing lists? yes
**Is your feature request related to a problem? Please describe.**
The configuration backend hook allows to put server parameters to the configuration database, but does not allow to put complex parameters/maps. For example, it would be great to be able to put the expired-leases-processing map in the database, particularly as its “semantics” apply to all the servers that share the same configuration items like subnets and shared networks. Enhancing the “global-parameter[46]-set” API parameters to allow maps would be a great addition.
**Describe the solution you'd like**
Enhance the remote-parameter[46]-set API parameter set to allow including maps so that, for example, the following API call would be a legitimate one:
```
{"command": "remote-global-parameter6-set"
"arguments": {
"parameters": {
"t1-percent": 0.85,
"renew-timer": 43200,
"expired-leases-processing": {
"reclaim-timer-wait-time": 600,
"flush-reclaimed-timer-wait-time": 4320,
"hold-reclaimed-time": 17280,
"max-reclaim-leases": 100,
"max-reclaim-time": 9999,
"unwarned-reclaim-cycles": 5
}
},
"remote": {"type": "mysql"}, "server-tags": [ "all" ]
}
}
```
**Describe alternatives you've considered**
Leave the parameters in the individual server config files, but that makes it painful to update the parameters across all servers.
**Additional context**
Other parameter maps could be considered, such as the dhcp-ddns one.
**Funding its development**
Kea is run by ISC, which is a small non-profit organization without any government funding or any permanent sponsorship organizations. Are you able and willing to participate financially in the development costs? This is a fairly minor development, I'd imagine... we are indirectly contributing by being paying subscriber :)
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature as generic as possible, so it can be used in wide variety of situations. That means the proposed solution may be a bit different that you initially thought. Are you willing to take part in the design discussions? Are you willing to test an unreleased engineering code? Sure.
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as e-mail, jabber id or a telephone, we may send you a message on github with questions when we have them.
You can reach me too on bbuclin@att.comkea2.5.5Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/3198vivso-suboptions not properly supported in Netconf2024-01-26T10:58:09ZDarren Ankneyvivso-suboptions not properly supported in NetconfAn example of configuration of `vivso-suboptions` is shown in the ARM (simplified here):
```
"Dhcp4": {
"option-data": [
{
"name": "vivso-suboptions",
"space": "dhcp4",
"data": "2234"
...An example of configuration of `vivso-suboptions` is shown in the ARM (simplified here):
```
"Dhcp4": {
"option-data": [
{
"name": "vivso-suboptions",
"space": "dhcp4",
"data": "2234"
},
{
"name": "vivso-suboptions",
"space": "dhcp4",
"data": "3561"
},
...
]
}
```
In the Kea yang definition found in: src/share/yang/modules/kea-dhcp4-server@2023-06-28.yang the keys are "code space" as shown here:
```
grouping option-data-list {
description "Option data list grouping.";
list option-data {
key "code space";
description "Option data entry.";
leaf code {
type uint8;
mandatory true;
description "Option code.";
}
leaf space {
type string;
mandatory true;
description "Option space.";
}
uses dhcp:option-data-name;
uses dhcp:option-data-data;
uses dhcp:option-data-csv-format;
uses dhcp:option-data-always-send;
uses dhcp:option-data-never-send;
uses dhcp:option-data-user-context;
}
}
```
which makes it impossible to create two option-data entries with the same space (dhcp4) and code (125 for VIVSO). This is as stated in [RFC6020](https://datatracker.ietf.org/doc/html/rfc6020#section-7.8.2):
> The combined values of all the leafs specified in the key are used to uniquely identify a list entry. All key leafs MUST be given values when a list entry is created.
So this `sysrepocfg` xml works:
```
<config xmlns="urn:ietf:params:xml:ns:yang:kea-dhcp4-server">
<subnet4>
<id>1</id>
<pool>
<start-address>192.168.20.100</start-address>
<end-address>192.168.20.200</end-address>
</pool>
<subnet>192.168.20.0/24</subnet>
</subnet4>
<option-data>
<code>125</code>
<space>dhcp4</space>
<data>2234</data>
</option-data>
<interfaces-config>
<interfaces>enp0s3</interfaces>
</interfaces-config>
<control-socket>
<socket-name>/tmp/kea-dhcp4-ctrl.sock</socket-name>
<socket-type>unix</socket-type>
</control-socket>
</config>
```
while this, with second entry for option 125, does not:
```
<config xmlns="urn:ietf:params:xml:ns:yang:kea-dhcp4-server">
<subnet4>
<id>1</id>
<pool>
<start-address>192.168.20.100</start-address>
<end-address>192.168.20.200</end-address>
</pool>
<subnet>192.168.20.0/24</subnet>
</subnet4>
<option-data>
<code>125</code>
<space>dhcp4</space>
<data>2234</data>
<code>125</code>
<space>dhcp4</space>
<data>3561</data>
</option-data>
<interfaces-config>
<interfaces>enp0s3</interfaces>
</interfaces-config>
<control-socket>
<socket-name>/tmp/kea-dhcp4-ctrl.sock</socket-name>
<socket-type>unix</socket-type>
</control-socket>
</config>
```
When an attempt to apply the configuration is made, the output is as follows:
```
$ sudo sysrepocfg -v debug -d startup -f xml -m kea-dhcp4-server --edit=startup4.xml
[INF] Connection 52 created.
[INF] Session 20 (user "root", CID 52) created.
libyang error: Invalid position of the key "code" in a list. (Data location "/kea-dhcp4-server:config/option-data[code='125'][space='dhcp4']/code", line number 14.)
sysrepocfg error: Data parsing failed
[INF] No datastore changes to apply.
```
Please see [SF1556](https://isc.lightning.force.com/lightning/r/Case/500S6000002qbYdIAI/view) for further details including some proposed solutions.kea2.5.5Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3229hammer.py prepare-system --just-configure2024-01-26T09:15:21ZAndrei Pavelandrei@isc.orghammer.py prepare-system --just-configureWe could use a way to just configure packages without installing them in hammer.We could use a way to just configure packages without installing them in hammer.kea2.5.5Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.org