ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-08-02T13:57:35Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/565harden demo deployment2021-08-02T13:57:35ZMichal Nowikowskiharden demo deployment0.19Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2008make install doesn't work with netconf enabled2021-07-30T17:22:13ZAndrei Pavelandrei@isc.orgmake install doesn't work with netconf enabled```
/usr/bin/install: omitting directory './hashes'
make[6]: *** [Makefile:495: install-yangmodulesDATA] Error 1
``````
/usr/bin/install: omitting directory './hashes'
make[6]: *** [Makefile:495: install-yangmodulesDATA] Error 1
```kea1.9.10Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2004No rule to make target 'check-hashes.sh', needed by 'all-am'.2021-07-30T10:32:29ZAndrei Pavelandrei@isc.orgNo rule to make target 'check-hashes.sh', needed by 'all-am'.When building from tarball with NETCONF support.
First reported in 1.9.10 sanity checks: https://gitlab.isc.org/isc-projects/kea/-/issues/2001#note_227952When building from tarball with NETCONF support.
First reported in 1.9.10 sanity checks: https://gitlab.isc.org/isc-projects/kea/-/issues/2001#note_227952kea1.9.10Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2001Sanity checks for Kea 1.9.10 rc12021-07-29T20:51:09ZjenkinsSanity checks for Kea 1.9.10 rc1```We are now at step SANITY CHECKS of Kea 1.9.10 rc1.
Please verify the packages and files according to "4. Sanity Checks" chapter on:
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks
and your imagination.
Be...```We are now at step SANITY CHECKS of Kea 1.9.10 rc1.
Please verify the packages and files according to "4. Sanity Checks" chapter on:
https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks
and your imagination.
Before starting any checks, please state what check you are doing in a
thread/discussion (not as comment) in Sanity Checks issue in GitLab:
When you finish given check state in the same thread/discussion what is the result.
This way we know what is covered upfront and we can avoid repeating ourselves.
Release content is located on:
1) [tarballs] repo.isc.org in the following folders:
/data/shared/sweng/kea/releases/1.9.10-rc1
/data/shared/sweng/kea/releases/premium-1.9.10-rc1
/data/shared/sweng/kea/releases/subscription-1.9.10-rc1
SHA256 (kea-1.9.10.tar.gz) = cee15bb816c708b527f26254123437e3335a6920c7790db342bfe8d2443a2583
SHA256 (kea-premium-1.9.10.tar.gz) = c6bf1bd49c40b8d1d75267ca4a14a881425e3addfa2fc952bb9adb7b614adfad
SHA256 (kea-subscription-1.9.10.tar.gz) = 1c0b110153708a333b0d5a3af40f6a3511b1b1ff06d1861c67b738dd6c5d36d8
2) [rpm/deb packages] on packages.isc.org, exact packages versions are stored here:
https://jenkins.aws.isc.org/job/kea-dev/job/pkg/458/
Release version is 1.9.10-r20210728141912 (please verify if it is this version while installing).
Install instruction is here: https://wiki.isc.org/bin/view/QA/KeaReleaseProcess, chapter 4. Sanity Checks, point 9.
```kea1.9.11https://gitlab.isc.org/isc-projects/kea/-/issues/1919ZTP with KEA for Huawei switches2021-07-29T14:50:36ZBranka AndrijasevicZTP with KEA for Huawei switchesHi ISC Support,
In the context of using KEA DHCP for ZTP of Huawei Switches, we’re right now facing an issue within the implementation of RFC Compliance within KEA DHCP.
Based on the documentation of Huawei (see https://support.hu...Hi ISC Support,
In the context of using KEA DHCP for ZTP of Huawei Switches, we’re right now facing an issue within the implementation of RFC Compliance within KEA DHCP.
Based on the documentation of Huawei (see https://support.huawei.com/enterprise/en/doc/EDOC0100533703?section=j004) the Switch Firmware is relying on the overlapping Options 141 + 146 (see https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#id2) which are conflicting in terms of DHCP Option Type.
We would therefore kindly ask ISC to review this issue, as it’s entirely blocking the introduction of ZTP / Autoconfiguration of Huawei Switches within our installation base.
In case no solution exists out of the box, we would further ask ISC to consider a compatibility option for allowing the override of standard RFC-ed options, see e.g. https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#kea-dhcpv4-compatibility-configuration-parameters
Kind Regardsoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2005Stork-Agent does not interprete include statement in kea-ctrl-agent.conf2021-07-29T14:19:23ZRobert SteinerStork-Agent does not interprete include statement in kea-ctrl-agent.confWhen using the <? include...?> statements in kea-ctrl-agent.conf for http-host and http-port, stork-agent does not follw the include, and so finds no http-port. 'http-port' and 'http-host' must be in the main kea-ctrl-agent.conf file.When using the <? include...?> statements in kea-ctrl-agent.conf for http-host and http-port, stork-agent does not follw the include, and so finds no http-port. 'http-port' and 'http-host' must be in the main kea-ctrl-agent.conf file.https://gitlab.isc.org/isc-projects/kea/-/issues/1997Kea ARM points to deprecated location for Kea Developers' Guide2021-07-28T19:05:02ZMichael McNallyKea ARM points to deprecated location for Kea Developers' GuidePer a discussion in chat today, the Kea team mentioned that the preferred reference location for the Developers' Guide is [https://reports.kea.isc.org/dev_guide/index.html](https://reports.kea.isc.org/dev_guide/index.html)
However, the ...Per a discussion in chat today, the Kea team mentioned that the preferred reference location for the Developers' Guide is [https://reports.kea.isc.org/dev_guide/index.html](https://reports.kea.isc.org/dev_guide/index.html)
However, the existing Kea ARM appears to point to a now-deprecated location on jenkins.isc.org: see the link in [ARM section 16.1](https://kea.readthedocs.io/en/latest/arm/hooks.html).https://gitlab.isc.org/isc-projects/kea/-/issues/1999build error when NETCONF and unit tests are enabled: ‘ASSERT_NO_THROW_LOG’ wa...2021-07-28T14:55:17ZAndrei Pavelandrei@isc.orgbuild error when NETCONF and unit tests are enabled: ‘ASSERT_NO_THROW_LOG’ was not declared in this scope```
adaptor_unittests.cc:28:5: error: ‘ASSERT_NO_THROW_LOG’ was not declared in this scope; did you mean ‘ASSERT_NO_THROW’?
28 | ASSERT_NO_THROW_LOG(context = Adaptor::getContext(json));
| ^~~~~~~~~~~~~~~~~~~
| ...```
adaptor_unittests.cc:28:5: error: ‘ASSERT_NO_THROW_LOG’ was not declared in this scope; did you mean ‘ASSERT_NO_THROW’?
28 | ASSERT_NO_THROW_LOG(context = Adaptor::getContext(json));
| ^~~~~~~~~~~~~~~~~~~
| ASSERT_NO_THROW
```kea1.9.10Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2804Release Checklist for BIND 9.11.34, BIND 9.11.34-S1, BIND 9.16.19, BIND 9.16....2021-07-28T13:05:20ZMichal NowakRelease Checklist for BIND 9.11.34, BIND 9.11.34-S1, BIND 9.16.19, BIND 9.16.19-S1, 9.17.16## Release Schedule
**Code Freeze:** Wednesday, June 30th, 2021
**Tagging Deadline:** Wednesday, July 12th, 2021
**Public Release:** Wednesday, July 21th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone ...## Release Schedule
**Code Freeze:** Wednesday, June 30th, 2021
**Tagging Deadline:** Wednesday, July 12th, 2021
**Public Release:** Wednesday, July 21th, 2021
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.17.16](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=July%202021%20(9.11.34%2C%209.11.34-S1%2C%209.16.19%2C%209.16.19-S1%2C%209.17.16)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.17)
- [9.16.19](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=July%202021%20(9.11.34%2C%209.11.34-S1%2C%209.16.19%2C%209.16.19-S1%2C%209.17.16)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.16)
- [9.11.34](https://gitlab.isc.org/isc-projects/bind9/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=July%202021%20(9.11.34%2C%209.11.34-S1%2C%209.16.19%2C%209.16.19-S1%2C%209.17.16)¬[label_name][]=Release%20Notes¬[label_name][]=Duplicate&label_name[]=v9.11)
**Merge requests merged into the milestone without a release note:**
- [9.17.16](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=July%202021%20(9.11.34%2C%209.11.34-S1%2C%209.16.19%2C%209.16.19-S1%2C%209.17.16)¬[label_name][]=Release%20Notes&target_branch=main)
- [9.16.19](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=July%202021%20(9.11.34%2C%209.11.34-S1%2C%209.16.19%2C%209.16.19-S1%2C%209.17.16)¬[label_name][]=Release%20Notes&target_branch=v9_16)
- [9.11.34](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=July%202021%20(9.11.34%2C%209.11.34-S1%2C%209.16.19%2C%209.16.19-S1%2C%209.17.16)¬[label_name][]=Release%20Notes&target_branch=v9_11)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.17.16](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=July%202021%20(9.11.34%2C%209.11.34-S1%2C%209.16.19%2C%209.16.19-S1%2C%209.17.16)&label_name[]=No%20CHANGES&target_branch=main)
- [9.16.19](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=July%202021%20(9.11.34%2C%209.11.34-S1%2C%209.16.19%2C%209.16.19-S1%2C%209.17.16)&label_name[]=No%20CHANGES&target_branch=v9_16)
- [9.11.34](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&milestone_title=July%202021%20(9.11.34%2C%209.11.34-S1%2C%209.16.19%2C%209.16.19-S1%2C%209.17.16)&label_name[]=No%20CHANGES&target_branch=v9_11)
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is in effect.
### Before the Tagging Deadline
- [x] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Update API files for libraries with new version information.
- [x] ***(QA)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(QA)*** Update `CHANGES`.
- [x] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update `README.md`.
- [x] ***(QA)*** Update `version`.
- [x] ***(QA)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is over.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### 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 *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription Edition (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public packages (`*.deb`, RPMs).
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Merge the automatically prepared `prep 9.x.y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_x`).
- [x] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Michal NowakMichal Nowak2021-07-21https://gitlab.isc.org/isc-projects/kea/-/issues/1892Deprecate Cassandra2021-07-28T12:58:34ZTomek MrugalskiDeprecate CassandraCassandra backend is by far the least popular and it is lagging behind. We looked at it and determined that it's not feasible to provide config backend implementation based on Cassandra.
For those two reasons, we're going to deprecate C...Cassandra backend is by far the least popular and it is lagging behind. We looked at it and determined that it's not feasible to provide config backend implementation based on Cassandra.
For those two reasons, we're going to deprecate Cassandra.
Cassandra will remain available in 2.x, but will be marked as deprecated. We will keep the code around as long as there are customers who still use it.kea1.9.9Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1998Changes for Kea 1.9.10 release2021-07-28T05:04:19ZMichal NowikowskiChanges for Kea 1.9.10 release- updated copyright years
- regenerated parsers
- regenerated message headers
- added release entry in ChangeLog
- update kea version- updated copyright years
- regenerated parsers
- regenerated message headers
- added release entry in ChangeLog
- update kea versionkea1.9.10https://gitlab.isc.org/isc-projects/bind9/-/issues/26699.16.15: dns_journal_compact failed: unexpected error2021-07-27T13:15:59ZThomas Amgarten9.16.15: dns_journal_compact failed: unexpected error<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
After upgrading one slave to 9.16.15, named reports errors on a couple of zones:
```
03-May-2021 02:10:41.333 general: error: slave/pluz.ch.hosts.jnw: journal file corrupt: expected serial 2021042500, got 2021050200
03-May-2021 02:10:41.333 general: error: zone pluz.ch/IN: dns_journal_compact failed: unexpected error
```
On a updated resolver, the same error for the "managed-keys.bind"-file:
```
30-Apr-2021 14:09:19.611 general: error: managed-keys.bind.jnl: journal file corrupt: expected serial 1824, got 1825
30-Apr-2021 14:09:19.611 general: error: managed-keys-zone: dns_journal_compact failed: unexpected error
```
### BIND version used
```
BIND 9.16.15 (Stable Release) <id:4469e3e>
```
### Steps to reproduce
It occurs sometimes on several zones
### What is the current *bug* behavior?
named reports errors on a couple of zones:
```
03-May-2021 02:10:41.333 general: error: slave/pluz.ch.hosts.jnw: journal file corrupt: expected serial 2021042500, got 2021050200
03-May-2021 02:10:41.333 general: error: zone pluz.ch/IN: dns_journal_compact failed: unexpected error
```
### What is the expected *correct* behavior?
### Relevant configuration files
### Relevant logs and/or screenshots
### Possible fixesJuly 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/kea/-/issues/1977Document client classes in the config backend2021-07-26T16:54:52ZMarcin SiodelskiDocument client classes in the config backendClient classes can now be stored in a MySQL database (config backend). We need to add relevant text in the Kea ARM and the ChangeLog.Client classes can now be stored in a MySQL database (config backend). We need to add relevant text in the Kea ARM and the ChangeLog.kea1.9.10Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1965Client class management commands in cb_cmds hooks library2021-07-26T16:54:52ZMarcin SiodelskiClient class management commands in cb_cmds hooks libraryThis ticket implements new commands for managing client classes in the config backend based on the design document: https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/client-classes-in-cb.This ticket implements new commands for managing client classes in the config backend based on the design document: https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/client-classes-in-cb.kea1.9.10Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1928Client classes in MySQL backend2021-07-26T16:54:51ZMarcin SiodelskiClient classes in MySQL backendExtend MySQL Config backend with new calls to manage client classes. It is a followup to #1920. Also see: https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/client-classes-in-cbExtend MySQL Config backend with new calls to manage client classes. It is a followup to #1920. Also see: https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/client-classes-in-cbkea1.9.10Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1972DHCP servers should fetch client classes from the config backend2021-07-26T16:54:51ZMarcin SiodelskiDHCP servers should fetch client classes from the config backendFollowing the work done in #1928, we need to extend the DHCPv4 and DHCPv6 servers to use client classes from the MySQL database. They should periodically fetch the classes whenever any of the classes have been added or modified.Following the work done in #1928, we need to extend the DHCPv4 and DHCPv6 servers to use client classes from the MySQL database. They should periodically fetch the classes whenever any of the classes have been added or modified.kea1.9.10Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1167Configuration Backend support for Class Definitions2021-07-26T16:54:49ZPeter DaviesConfiguration Backend support for Class DefinitionsCB support for saving Class Definitions is on the roadmap - this feature request has been created to help the customer trace the progress of this development se [RT](https://support.isc.org/Ticket/Display.html?id=16186)CB support for saving Class Definitions is on the roadmap - this feature request has been created to help the customer trace the progress of this development se [RT](https://support.isc.org/Ticket/Display.html?id=16186)kea1.9.10Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1984bump up lib versions for the release 1.9.102021-07-26T16:47:53ZWlodzimierz Wencelbump up lib versions for the release 1.9.10kea1.9.10Razvan BecheriuRazvan Becheriuhttps://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/1976shorten the length of the server tag.2021-07-26T14:43:08ZPeter Daviesshorten the length of the server tag.Do we want to shorten the length tag field it's 256?
and modify upgrade script to check the size of the column and adjust accordingly.
[RT #18583](https://support.isc.org/Ticket/Display.html?id=18583)Do we want to shorten the length tag field it's 256?
and modify upgrade script to check the size of the column and adjust accordingly.
[RT #18583](https://support.isc.org/Ticket/Display.html?id=18583)kea1.9.10Marcin SiodelskiMarcin Siodelski