ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2019-08-20T19:06:53Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/831Proposed new SW Support and Release Versioning Policy2019-08-20T19:06:53ZVicky Riskvicky@isc.orgProposed new SW Support and Release Versioning PolicyWith the release of Kea 1.6 we plan to change the release model. We need to update our software support and versioning policy accordingly. I will also publish a short blog or email to bind-users or both on the topic, once we are all clea...With the release of Kea 1.6 we plan to change the release model. We need to update our software support and versioning policy accordingly. I will also publish a short blog or email to bind-users or both on the topic, once we are all clear on what the changes are.
Below is proposed text for the new Software Support and Version Numbering policy (https://kb.isc.org/docs/aa-00896) for review. It is intended to be as much like the BIND statement as applicable.
One thing we have not addressed - it says we won't add new features to existing stable versions, but what about new hook libraries? IMHO that is a grey area. If a customer wanted us to create a new hook library, I am assuming we probably would create it on/with the current stable version, not the development version.
We might need some sort of general statement about hook libraries, versioning and support.
===================
**Kea**
With the release of Kea 1.6.0, we are changing our release model for Kea.
We will have two types of major Kea versions: Development and Stable. At any given time, we should have at least two options available, one or more Stable and one Development release.
**Development versions**
We release development versions off of the current working (master) branch. These will be the odd-numbered minor versions, starting from Kea 1.7.0.
There is no fixed schedule to development releases; new versions will be made available as new features or changes become ready for field testing. Maintenance releases on development branches will introduce new and updated features and may not be backward-compatible with their immediate predecessor. Development versions of Kea are suitable for those interested in experimenting with and providing feedback to ISC, but are not recommended for production use. There will be no alpha/beta/release candidate versions of development versions, and it may sometimes happen that a recently-released minor version is superseded very quickly in order to address a flaw. We may not issue patch releases for development versions with security bugs, at our discretion.
Development versions will be maintained until the next Stable version is created, at which time we will begin a new development branch (with the next odd number). We estimate development versions will mature into stable versions in less than a year, but this is a prediction, not a promise.
**Stable versions**
Beginning with Kea 1.6, we plan stabilize all the even-numbered minor versions for production use – for example, Kea 1.6 and Kea 1.8 will be stable versions. Each of these branches will have a series of maintenance releases, such as Kea 1.6.1, 1.6.2, etc. Maintenance releases on a Stable version will include bug fixes only, to maximize stability.
Stable versions of Kea are fully supported for 6 months after the next stable version is released. This means you should have ample time to migrate to a new stable version before the older one is EOL. We do not yet have ‘Extended Support’ versions of Kea. We still have a very high rate of new feature development and are not yet ready for a very long-lived stable branch. We expect to be able to update the ISC Kea packages the same day we post the tarballs.
* Kea 1.3 went to EOL in December 2018
* Kea 1.4 will be supported until August 2019 (or until we release Kea 1.6)
* Kea 1.5 will be supported until we release Kea 1.8.
* Kea 1.6 will be a stable version, supported for 6 months after we release Kea 1.8, or until we release Kea 2.0, whichever is sooner.
* Kea 1.7 will be a development version supported until we release Kea 1.9
* Kea 1.8 will be the next stable version after 1.6
———————
**OLD Policy (Currently published policy)** https://kb.isc.org/docs/aa-00896
All Kea releases to date include new features and are considered development releases. We will continue doing this to keep up with the pace of new development until further notice. Currently, we are issuing updates every 4-6 months, and there is no such thing as a maintenance-only release. ISC offers support for the current, and immediate prior, regularly-released versions of Kea. As the product matures, we plan on supporting both maintenance and development branches.
* Kea 1.3 went to EOL in December 2018
* Kea 1.4 will be supported until July 2019 (or until we release Kea 1.6)
* Kea 1.5 will be supported until December 2019 (or until we release Kea 1.7)
Other General Policy Guidelines
* Standard support terms do not apply to developmental releases, the Supported Preview edition, or alpha, beta, and Release Candidates (RCs). These are typically shorter-lived releases.
* We reserve the right to change our version numbering for Kea.
* We also reserve the right, based on these changes, to include some minor features in point releases (e.g. 9.8.1) for BIND 9 and ISC DHCP.Kea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/826documentation of cb_cmds embedded commands2019-08-14T20:59:01ZFrancis Dupontdocumentation of cb_cmds embedded commandsKea1.6-finalhttps://gitlab.isc.org/isc-projects/kea/-/issues/824sphinx docs cannot be built on ReadTheDocs2019-08-13T11:17:00ZMichal Nowikowskisphinx docs cannot be built on ReadTheDocsKea1.6-finalMichal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/814hammer: disable building debugsource rpm package2019-08-09T07:01:34ZMichal Nowikowskihammer: disable building debugsource rpm packageKea1.6-finalMichal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/810sphinx documentation generates invalid json data2019-08-16T18:05:17ZRazvan Becheriusphinx documentation generates invalid json datathere are several documents that generate invalid json datathere are several documents that generate invalid json dataKea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/809Sphinx fix after #777 merge2019-08-07T15:18:08ZTomek MrugalskiSphinx fix after #777 mergeThe #777 merge introduced code change that causes some Sphinx versions to fail.
It did work on my ubuntu 18.04 with sphinx 1.6.7, but it fails on Jenkins (version unknown).
Anyway, need to fix this.The #777 merge introduced code change that causes some Sphinx versions to fail.
It did work on my ubuntu 18.04 with sphinx 1.6.7, but it fails on Jenkins (version unknown).
Anyway, need to fix this.Kea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/807api2doc.py and mes2doc.py should be run from sphinx's conf.py2019-08-09T12:24:47ZMichal Nowikowskiapi2doc.py and mes2doc.py should be run from sphinx's conf.pyso that api.rst and kea-messages.rst are also generated and present on RTDso that api.rst and kea-messages.rst are also generated and present on RTDKea1.6-finalhttps://gitlab.isc.org/isc-projects/kea/-/issues/806hammer.py fails on clean OS due to missing deps for sphinx on debian/ubuntu2019-08-07T05:26:26ZMichal Nowikowskihammer.py fails on clean OS due to missing deps for sphinx on debian/ubuntuKea1.6-finalMichal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/804CB: doc never says clearly how to configure server-tag on a server2019-11-25T17:37:11ZTomek MrugalskiCB: doc never says clearly how to configure server-tag on a serverPerhaps I missed it, but I couldn't find in the docs how to tell Kea instance what is its server tag.
I finally managed to get it by looking at the code.
The doc/examples/kea{4,6}/config-backend.json and Kea ARM should be updated.Perhaps I missed it, but I couldn't find in the docs how to tell Kea instance what is its server tag.
I finally managed to get it by looking at the code.
The doc/examples/kea{4,6}/config-backend.json and Kea ARM should be updated.Kea1.6-finalFrancis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/801CB: Adding basic IPv6 subnet results in 0 lifetimes2019-08-07T16:31:21ZTomek MrugalskiCB: Adding basic IPv6 subnet results in 0 lifetimesI've configured CB and sent the following command:
```
echo ' "subnets": [ { "id": 100, "subnet": "2001:db8:1::/48", "shared-network-name": "", "pools": [ { "pool": "2001:db8:1::/64" } ] } ], "server-tags": [ "all" ] ' | kea-shell --hos...I've configured CB and sent the following command:
```
echo ' "subnets": [ { "id": 100, "subnet": "2001:db8:1::/48", "shared-network-name": "", "pools": [ { "pool": "2001:db8:1::/64" } ] } ], "server-tags": [ "all" ] ' | kea-shell --host ::1 --port 8000 --service dhcp6 remote-subnet6-set
```
and Kea printed out this:
```
2019-08-05 14:43:49.228 INFO [kea-dhcp6.dhcpsrv/89148] DHCPSRV_CFGMGR_NEW_SUBNET6 a new subnet has been added to configuration: 2001:db8:1::/48 with params preferred-lifetime=0, valid-lifetime=0, rapid-commit is disabled
```
This isn't correct. The problem lies with the log message itself, the underlying subnet structure seems to be configured correctly. There's a pref=3600, valid=7200 global value, with no specific lifetimes specified on subnet level, so global values are used.
Perhaps we need to get rid of the lifetimes printed or alternatively print zeros as "0 (use global or shared-network values)".
Since this seems to be logging only issue, treating as low.Kea1.6-finalhttps://gitlab.isc.org/isc-projects/kea/-/issues/797Meta-package for Kea2019-08-03T04:43:03ZVicky Riskvicky@isc.orgMeta-package for KeaThere are now hundreds of Kea packages in the repo on Cloudsmith.io. A typical user will need to install a Kea dhcpv4 or v6 package, plus the LFC package, plus the CA package... I understand that we created all these component packages i...There are now hundreds of Kea packages in the repo on Cloudsmith.io. A typical user will need to install a Kea dhcpv4 or v6 package, plus the LFC package, plus the CA package... I understand that we created all these component packages in order to be consistent with the existing downstream OS-project provided packages, but it doesn't seem like we have achieved the best usability possible here.
Can we create a 'meta package' that installs 'everything most people need'.Kea1.6-finalhttps://gitlab.isc.org/isc-projects/kea/-/issues/790bring back -git suffix to kea version2019-08-02T12:04:57ZMichal Nowikowskibring back -git suffix to kea versionKea1.6-finalMichal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/780API Reference (Appendix A) is missing2019-08-09T12:29:56ZFrancis DupontAPI Reference (Appendix A) is missingBefore sphinx you had the appendix A API Reference with 131 entries. Now you have nothing?Before sphinx you had the appendix A API Reference with 131 entries. Now you have nothing?Kea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/777hook api and messages docs generation into sphinx/RTD process2019-08-09T10:57:18ZMichal Nowikowskihook api and messages docs generation into sphinx/RTD processKea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/768benchmarks do not compile after removing lease t1 and t22019-08-01T10:41:56ZRazvan Becheriubenchmarks do not compile after removing lease t1 and t2benchmarks do not compile after removing lease t1 and t2
```
generic_lease_mgr_benchmark.cc: In member function ‘void isc::dhcp::bench::GenericLeaseMgrBenchmark::prepareLeases6(const size_t&)’:
generic_lease_mgr_benchmark.cc:168:16: erro...benchmarks do not compile after removing lease t1 and t2
```
generic_lease_mgr_benchmark.cc: In member function ‘void isc::dhcp::bench::GenericLeaseMgrBenchmark::prepareLeases6(const size_t&)’:
generic_lease_mgr_benchmark.cc:168:16: error: ‘struct isc::dhcp::Lease6’ has no member named ‘t1_’
lease->t1_ = i;
^~~
generic_lease_mgr_benchmark.cc:169:16: error: ‘struct isc::dhcp::Lease6’ has no member named ‘t2_’
lease->t2_ = i;
^~~
Makefile:677: recipe for target 'run_benchmarks-generic_lease_mgr_benchmark.o' failed
```Kea1.6-finalRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/764Developer documentation not being built correctly2019-08-02T11:49:57ZStephen MorrisDeveloper documentation not being built correctlyCommit: 812418169c0b95ad1b911cc602a55a47741d6e43 (latest master at the time of writing)
The developer documentation, when built with `cd doc/devel ; make devel` appears to omit a lot of the developer documentation. In addition, that wh...Commit: 812418169c0b95ad1b911cc602a55a47741d6e43 (latest master at the time of writing)
The developer documentation, when built with `cd doc/devel ; make devel` appears to omit a lot of the developer documentation. In addition, that which is present seems to be in a random order. The two attachments show the contents pane as it was (the screenshot omits the bottom few items):
![Screenshot_2019-07-31_at_17.43.32](/uploads/c5281bf9d07a0287a98ac350406e2001/Screenshot_2019-07-31_at_17.43.32.png) ... and as it is now: ![Screenshot_2019-07-31_at_17.43.15](/uploads/1f631575a348584f0c218748d8f376bd/Screenshot_2019-07-31_at_17.43.15.png)Kea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/762running sphinx-build in parallel sometimes fails2019-08-01T14:08:39ZMichal Nowikowskirunning sphinx-build in parallel sometimes failsKea1.6-finalMichal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/761Extend use of quoting mechanism for circuit-id to allow string initializers f...2019-08-15T16:08:56ZThomas MarkwalderExtend use of quoting mechanism for circuit-id to allow string initializers for binary optionsWe currently support setting "circuit-id" in host reservations by embedding a text string in sinqle-quotes:
```
"circuit-id": "'charter950'",
```
Allowing this syntax for any binary option would be very convenient for users:
```...We currently support setting "circuit-id" in host reservations by embedding a text string in sinqle-quotes:
```
"circuit-id": "'charter950'",
```
Allowing this syntax for any binary option would be very convenient for users:
```
{
# Supply option 43,sub option 1 string data
"name": "the-url",
"code": 1,
"data": "'https://example.this-is-a-long-url.imagine-it-as-hex-sting.com'",
"space": "example-space"
}
```
This allows users to readily support options that carry string data but can be empty. See #719 and #750.Kea1.6-finalTomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/760manpages levels in TOC in sphinx docs are wrong2019-07-31T14:02:32ZMichal Nowikowskimanpages levels in TOC in sphinx docs are wrongKea1.6-finalMichal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/748Expand @libdir@ in samples2019-08-02T19:55:47ZFrancis DupontExpand @libdir@ in samplesDetected in 1.6-beta2 sanity checks (#746): keactrl can provide a sample configuration file with an expanded @libdir@.Detected in 1.6-beta2 sanity checks (#746): keactrl can provide a sample configuration file with an expanded @libdir@.Kea1.6-finalFrancis DupontFrancis Dupont