Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2019-11-25T17:48:43Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/88Create config backend design2019-11-25T17:48:43ZMarcin SiodelskiCreate config backend designThe Config Backend design is available at: https://gitlab.isc.org/isc-projects/kea/wikis/designs/configuration-in-db-design
Please review and put your comments into the issue.The Config Backend design is available at: https://gitlab.isc.org/isc-projects/kea/wikis/designs/configuration-in-db-design
Please review and put your comments into the issue.kea1.7.2Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1033Daemon proc_name_ is now a static value.2019-11-26T09:26:24ZFrancis DupontDaemon proc_name_ is now a static value.#50 made proc_name_ a Daemon class value but failed to update unit tests introducing a dependency in unit test execution order.#50 made proc_name_ a Daemon class value but failed to update unit tests introducing a dependency in unit test execution order.kea1.7.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/1031lib bump up for kea 1.7.22019-11-26T11:20:54ZWlodzimierz Wencellib bump up for kea 1.7.2kea1.7.2https://gitlab.isc.org/isc-projects/kea/-/issues/985Relax timings in new config-backend-pull unit tests2019-11-19T18:37:24ZFrancis DupontRelax timings in new config-backend-pull unit testsand update the unit test names too.and update the unit test names too.kea1.7.2https://gitlab.isc.org/isc-projects/kea/-/issues/964HA primary gets stuck spinning on a perpetually ready external socket2019-12-12T17:02:15ZThomas MarkwalderHA primary gets stuck spinning on a perpetually ready external socketThis stems from https://support.isc.org/Ticket/Display.html?id=15378.
It is possible for the HA primary server to get into a state where an external socket is apparently marked ready and never cleared/satisfied. This causes the server ...This stems from https://support.isc.org/Ticket/Display.html?id=15378.
It is possible for the HA primary server to get into a state where an external socket is apparently marked ready and never cleared/satisfied. This causes the server to starve DHCP socket reading by endlessly detecting the external socket and eating 100% CPU. This condition is most easily reproduced using a 3 server HA hot-standby setup: primary, standby, and backup. It does not appear to be DHCP traffic volume issue, rather it appears simply be a code hole in the socket management.
I have attached the primary server config file I used. (The other servers files are the same except for HA server name).
I have only tested with v6, but the customer supplied top output shows both v4 and v6 servers eating CPU. I am pretty confident the issue is common to both.
[ha_3_server.conf](/uploads/8a3bbe0fba0abc75190600842964ea76/ha_3_server.conf)
NOTE: Further analysis demonstrates this condition is possible, but far less likely in two server HA setups.kea1.7.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/960MySQL connection pool2019-11-20T09:39:57ZFrancis DupontMySQL connection poolkea1.7.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/883create thread pool2020-02-13T11:41:39ZRazvan Becheriucreate thread poolcreate thread pool to be used for different multi threading processing taskscreate thread pool to be used for different multi threading processing taskskea1.7.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/850Unable to set "interface" for a subnet via remote-subnet4-set when such inter...2019-11-25T16:44:05ZMarcin SiodelskiUnable to set "interface" for a subnet via remote-subnet4-set when such interface is not present in the systemThe cb_cmds uses Kea parsers to parse the subnet information received via commands. The parsers were initially designed to parse local Kea configuration files. The subnet parser, for example, checks whether the interface set for a subnet...The cb_cmds uses Kea parsers to parse the subnet information received via commands. The parsers were initially designed to parse local Kea configuration files. The subnet parser, for example, checks whether the interface set for a subnet is present in the system. If it is not, it spits out an error similar to this:
```
[ { "result": 1, "text": "subnet configuration failed: Specified network interface name vboxnet0 for subnet 192.168.50.0/24 is not present in the system (:0:0)" } ]
```
This shouldn't be the case when setting the configuration via the CB, because a given server should be able to set the configuration for any DHCP server, not necessarily for itself.kea1.7.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/813come up with updated release model for 1.7 and onwards2019-11-13T19:14:50ZTomek Mrugalskicome up with updated release model for 1.7 and onwardsWe're changing the release process after 1.6.0 is our the door. We had discussions about that couple months ago and it now time to put this into reality.
We need:
* [x] a good process description for developers - [release process page]...We're changing the release process after 1.6.0 is our the door. We had discussions about that couple months ago and it now time to put this into reality.
We need:
* [x] a good process description for developers - [release process page](https://gitlab.isc.org/isc-projects/kea/wikis/processes/Release-process)
* [x] a short version for release notes for users to understand (a paragraph would be best) - see [1.6.0 release notes](https://gitlab.isc.org/isc-projects/kea/wikis/release%20notes/release-notes-1.6-final#changes-to-release-model)kea1.7.2Vicky Riskvicky@isc.orgVicky Riskvicky@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/793Default port in CA config does not match default kea-shell config2019-11-25T16:27:28ZTomek MrugalskiDefault port in CA config does not match default kea-shell configThe example config that gets installed in /etc/kea/kea-ctrl-agent.conf uses port 8080, but kea-shell uses 8000 by default.
As a result, in the default configuration you need to pass extra switches, even though the software could work ou...The example config that gets installed in /etc/kea/kea-ctrl-agent.conf uses port 8080, but kea-shell uses 8000 by default.
As a result, in the default configuration you need to pass extra switches, even though the software could work out of the box.kea1.7.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/785Get rid of xsltproc including XSLTPROC_NET2019-11-19T07:02:20ZFrancis DupontGet rid of xsltproc including XSLTPROC_NETNo longer used but there are still references to it, e.g. in the ARM about --enable-generate-docs...No longer used but there are still references to it, e.g. in the ARM about --enable-generate-docs...kea1.7.2https://gitlab.isc.org/isc-projects/kea/-/issues/765sys/fcntl.h should be replaced by fcntl.h2019-11-22T04:06:00ZFrancis Dupontsys/fcntl.h should be replaced by fcntl.hCompile Kea on Alpine Linux I got some warnings about:
```
/usr/include/sys/fcntl.h:1:2: warning: #warning redirecting incorrect #include <sys/fcntl.h> to <fcntl.h> [-Wcpp]
```
Even it is very minor it is something very easy to fix...Compile Kea on Alpine Linux I got some warnings about:
```
/usr/include/sys/fcntl.h:1:2: warning: #warning redirecting incorrect #include <sys/fcntl.h> to <fcntl.h> [-Wcpp]
```
Even it is very minor it is something very easy to fix...kea1.7.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/596Add a hook-point for post reconfiguration2019-11-25T16:01:27ZThomas MarkwalderAdd a hook-point for post reconfigurationWe've discussed the potential usefulness of having a hook point that occurs immediately following a reconfiguration. With the rollout of CB, now might be a good time to add it. I believe Francis has a specific RADIUS related use case a...We've discussed the potential usefulness of having a hook point that occurs immediately following a reconfiguration. With the rollout of CB, now might be a good time to add it. I believe Francis has a specific RADIUS related use case as well.kea1.7.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/572perfdhcp should count only valid responses2019-11-20T06:53:58ZRazvan Becheriuperfdhcp should count only valid responsesperfdhcp ignores the ADVERTISE message and just goes on with REQUEST, counting NACK as valid lease.
Another thing to check is that the addresses assigned are really unique.perfdhcp ignores the ADVERTISE message and just goes on with REQUEST, counting NACK as valid lease.
Another thing to check is that the addresses assigned are really unique.kea1.7.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/466kea-admin lease-* options to be renamed to db-*2019-11-20T08:58:34ZWlodzimierz Wencelkea-admin lease-* options to be renamed to db-*for now kea-admin options looks like that:
```
wlodek@debian9-64-2:sbin $ ./kea-admin
ERROR/kea-admin: missing command
kea-admin 1.5.0-git
This is a kea-admin script that conducts administrative tasks on
the Kea installation.
Usa...for now kea-admin options looks like that:
```
wlodek@debian9-64-2:sbin $ ./kea-admin
ERROR/kea-admin: missing command
kea-admin 1.5.0-git
This is a kea-admin script that conducts administrative tasks on
the Kea installation.
Usage: ./kea-admin COMMAND BACKEND [parameters]
COMMAND: Currently supported operations are:
- lease-init: Initializes new lease database. Useful for first time installation.
- lease-version: Checks version of the existing lease database scheme. Useful
- for checking lease DB version when preparing for an upgrade.
- lease-upgrade: Upgrades your lease database scheme
- lease-dump: Dump current leases to a CSV file
```
But now we use one db schema for leases and config. I propose to update commands `lease-init, lease-version, lease-upgrade, lease-dump` for more suitable names. Having said that - I don't have propositions for new names.kea1.7.2https://gitlab.isc.org/isc-projects/kea/-/issues/274Possible improvements to dhcp-queue-control member parsing2019-11-25T17:27:53ZThomas MarkwalderPossible improvements to dhcp-queue-control member parsingThe following discussion from !120 should be addressed:
- [ ] @fdupont started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/120#note_31593): (+1 comment)
> This can be postponed but the dhcp-queue-syntax i...The following discussion from !120 should be addressed:
- [ ] @fdupont started a [discussion](https://gitlab.isc.org/isc-projects/kea/merge_requests/120#note_31593): (+1 comment)
> This can be postponed but the dhcp-queue-syntax is not defined enough:
> - you should create a context for the two keywords
> - to make it easy to extend just add a STRING COLON value rule (value is the generic JSON value defined at the beginning of dhcpX_parser.yy and is used for instance to define a generic mao, cf map_value rule)
@tmark
The basic rules for dhcp-queue-control are:
1. Require enable-queue
2. Ensure that if queue-type is specified, it is a string (it can have any arbitrary value)
3. beyond those two rules, it can contain arbitrary content
I wasn't sure how to go about accomplishing rule 3, and do not want to use user-context. The parsing that is in place does what is needed but I am open to suggestions.kea1.7.2Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/9771.7.1 rc1 sanity checks2019-11-26T12:59:16ZWlodzimierz Wencel1.7.1 rc1 sanity checks```
@repo.isc.org /data/shared/sweng/kea/releases/1.7.1-rc1
@repo.isc.org /data/shared/sweng/kea/releases/subscription-1.7.1-rc1
@repo.isc.org /data/shared/sweng/kea/releases/premium-1.7.1-rc1
SHA256 (1.7.1-rc1/kea-1.7.1.tar.gz) = ...```
@repo.isc.org /data/shared/sweng/kea/releases/1.7.1-rc1
@repo.isc.org /data/shared/sweng/kea/releases/subscription-1.7.1-rc1
@repo.isc.org /data/shared/sweng/kea/releases/premium-1.7.1-rc1
SHA256 (1.7.1-rc1/kea-1.7.1.tar.gz) = 13c28cdf48d44b495625f8724915497520d5996febb2e086df19795abbaaa0fe
SHA256 (subscription-1.7.1-rc1/kea-subscription-1.7.1.tar.gz) = 1c28d8c9aef3c256e95594d483b5d185a6c49b5fe818ee3298274f9eaa47881d
SHA256 (premium-1.7.1-rc1/kea-premium-1.7.1.tar.gz) = 3e7acf128ec43f9476e835f04972a56583d72777fee457ad847136a253f2fb0f
SHA256 (1.7.1-rc1/doc/html) = 3db6e59966507fd9d2a9c5a54841432b9332bdfa9cf873d26f291ef97f1b4a6c
SHA256 (1.7.1-rc1/doc/kea-arm.pdf) = 6fd3d921afdcd7808cdda030f6d35f0a09fb28488c7904050a2b3ad9656db89c
SHA256 (1.7.1-rc1/doc/kea-messages.pdf) = de3c677582d2167170f9b76bbf3a2fc1cb275b2c79fe0a0df268ce025e8c35a2
```
deb/rpm version - 1.7.1-isc0005220191029092134
due to the problems our internal nexus is actually having newest packages aren't treated as newest so I think that the only way to download and install release deb/rpm is:
- go to: https://jenkins.isc.org/job/kea-1.7/job/pkg/67/
- find your system on the list, e.g https://jenkins.isc.org/job/kea-1.7/job/pkg/67/artifact/debian-10-pkgs.txt
- copy name of the package you want to install
- go to packages.isc.org and search for this particular rpm/deb
- click on it and... you will download a file.
example of download link: https://packages.isc.org/repository/kea-1.7-ubuntu-18.04-ci/pool/i/isc-kea-dhcp4-server/isc-kea-dhcp4-server_1.7.1-isc0005220191029092134_amd64.deb
sorry for the inconvenience, issue with nexus was discovered recently and we didn't have time to fix it.kea1.7.2https://gitlab.isc.org/isc-projects/kea/-/issues/9741.7.1 release2019-11-20T08:26:04ZWlodzimierz Wencel1.7.1 release---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Process
## Introduction
The Kea release process (for the base version of Kea and the hooks) is different to that of DHCP. At t...---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Process
## Introduction
The Kea release process (for the base version of Kea and the hooks) is different to that of DHCP. At the moment, Kea has only one supported release at a time, so the process tries to ensure that any modifications needed for a release take place on the master branch, rather than on a version-specific one. The basic steps for a release are:
1) Announce a code freeze for the master branch that will last until actual tarball release
2) Do all necessary changes to the master branch for the release
3) Create release tarball from master branch
4) After sanity checks made by the QA and development teams, either we continue or we accept changes on master to fix issues if needed and go back to the previous step.
5) Create a release branch (for beta) or merge master to existing release branch (for final) and tag release on it. (???)
6) Sign and upload tarballs
7) Announce that freeze time on master branch is over.
8) Release tarballs are prepared by Jenkins job: https://jenkins.isc.org/job/kea-master-tarball-internal/. When given tarball is accepted for releasing it is pushed to repo.isc.org using Jenkins job: https://jenkins.isc.org/job/kea-release-upload-internal/
## Pre-Release Preparation
Some of those checks and updates can be made before actual freeze, but it's reasonable to announce freeze now!
- [x] 1. Check Jenkins results:
* Number of unit tests and system tests failing
* Is there a change in system tests pass rate? *Notify the development team of the overall Jenkins status
* Look into tarball check report " Kea Build Checks" on last tarball build and check if there is nothing suspicious (add/removed files, etc), verify that with developers:
* Compare current release package with code in repository
* Compare current release package with previous release package
- [x] 2. Is the distcheck passing on kea and kea+premium (https://jenkins.isc.org/job/kea-master-distcheck/)?
* Highlight any issues that require fixing.
- [x] 3. Check perflab if there is no critical errors there (https://perflab.isc.org/)
- [ ] 4. Make sure that there is no pending ticket to merge! (Use GitLab https://gitlab.isc.org/isc-projects/kea/merge_requests and https://gitlab.isc.org/isc-private/kea-premium/merge_requests or contact the development team).
- [x] 5. Check the Known Issues list, is there something that suppose to be fixed before release and was omitted?
- [x] 6. Check versioning:
* Ask the development team if the library versions are being updated (there is a step to check it later).
* Ask the development team if the HOOKS_VERSION is being updated.
- [x] 7. Create Release Notes on Kea GitLab wiki using standard template, update all dates and versions. This wiki page should created under "release notes" folder, like this one: release-notes-1.5-final
- [x] 8. Check if there is a Release Checklist ready. If not, create new one using this template (page could have been created, check Releases section at the bottom of this page)
The following steps may involve changing files in the repository. If any files will be updated, create a Kea ticket for them and make the changes on a separate branch.
- [x] 1. Check User's Guide sections:
* Chapter 1. Introduction
- On what platforms we are running tests using Jenkins? Update Supported Platforms
- Did we add any additional 3rd party software? Update if needed
- Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
* Chapter 2. Quick Start
- Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
* Chapter 3. Installation
- Check installation hierarchy
- Check and update Building Requirements
- Check configure options against what ./configure -h says
- [x] 2. Check !ChangeLog entries in Kea main and premium:
* Spelling, missing numbers, trailing whatspaces? (some of that is checked in every build of tarball-internal Jenkins job)
* Update Release Notes with !ChangeLog entries
- [x] 3. Check AUTHORS, INSTALL, README files in Kea main and premium.
- [x] 4. Update information in sources about copyright dates, new version, etc. This is done manually using script https://gitlab.isc.org/isc-private/qa-dhcp/blob/master/kea/build/prepare_kea_release.sh
- [x] 5. Regenerate parsers using docs.isc.org:
* download kea repo
```
cd kea; autoreconf -fi; ./configure --with-log4cplus=/home/wlodek/log4cplus --enable-generate-parser (log4cplus in /home/wlodek should be available for everyone, if not - download your own)
export PATH=/home/fdupont/bin:$PATH
cd ~/kea/src/bin/dhcp4; touch *.yy; make parser
cd ~/kea/src/bin/dhcp6; touch *.yy; make parser
cd ~/kea/src/bin/d2; touch *.yy; make parser
cd ~/kea/src/bin/agent; touch *.yy; make parser
cd ~/kea/src/bin/netconf/; touch *.yy; make parser
cd ~/kea/src/lib/eval; touch *.yy; make parser
```
TODO: we should regenerate all of them or just the one that been modified?
If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the branch to master.
## Build selection and upload package
That is the last moment to freeze code!
- [x] 1. Update release version in configure.ac and remove -git suffix, and commit the change on master. From that moment all tarball builds can be officially released.
- [x] 2. Go to tarball-internal Jenkins job and pick last tarball build - it will be a release candidate.
- [x] 3. Tarball checks before requesting sanity checks from dev team
* Download tarballs from picked jenkins build
Untar packages:
* Check sizes - is new package reasonable?
* Check installation tree, compare it with previous release
* Check installed lib versions
* which were updated? (save results)
* any of the lib from current release has lower number then corresponding lib from previous release? (!)
* Uninstall Kea, check what left (there should be just configuration files)
* Check if all of installed binaries has man page
* if not, is it in the tarball?
* are man page up-to-date?
* Check if documentation is properly formatted, has correct versions and dates.
* it's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid
- [ ] 4. If all seems to be ok then upload tarballs to repo.isc.org
* Go to release-upload Jenkins job
* Click "Build with Parameters"
* In field "Tarball" select picked tarball build
* In field "Release_Candidate" pick:
* rc1 if this is the first selected build for release, it will push selected tarballs to repo.isc.org, to folder suffixed with indicated rc#
* next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in error)
* final if the last rc number was ok, this will push selected tarbal to repo.isc.org, to folder with no suffixes
- [x] 5. If none of the results force you to fix and rebuild package, send sanity check request by an email to dhcp-team@isc.org and qa@isc.org with indicating paths with tarballs on repo.isc.org asking for sanity checks
## Sanity checks proposals:
- [x] 1. Check documentation:
* users guide:
- dates, versions, installation instructions both for kea and premium, formatting
- if you have time - read as much as you can.
* man pages:
- dates, versions, is it up-to-date? or usage changed between releases?
- does every binary has it's own .8 page?
- [x] 2. Check tarball content:
* compare tarball against repo (does some of the not included files should actually be included?)
* does premium tarballs include correct hooks? (any missing files?)
- [x] 3. compile:
* configure warnings?
* build warnings?
- [x] 4. run unit tests with various db backends, install (check tree), uninstall (check tree)
- [x] 5. Check example configurations
- [x] 6. Check release notes (not included in tarball)
- [x] 7. Check AUTHORS, INSTALL, COPYING, README files
- [x] 8. Check db update scripts:
* tarball inlcude the last one? (compare with repo)
## Releasing tarballs:
- [x] 1. Write an email to signers@isc.org requesting signatures of final tarballs on repo.isc.org indicating release folders. - Attach SHA256 checksums from tarball-internal logs.
- [ ] 2. Make release branch (e.g. v1_5_0 one branch for beta and final, with tags for both releases)
- [x] 3. Upload Release Notes to repo.isc.org
- [x] 4. When release packages are signed then upload them from repo.isc.org to ftp:
* make-available --public --symlink=cur /data/shared/sweng/kea/releases/1.4.0-beta
* make-available --private /data/shared/sweng/kea/releases/premium-1.4.0-beta/
* make-available --private /data/shared/sweng/kea/releases/subscription-1.4.0-beta/
- [x] 5. Contact support or marketing to upload packages to www.isc.org/downloads
- [x] 6. Contact marketing to upload premium packages to 'products' in web store
- [x] 7. Contact support to deliver premium and subscriber-only hooks to Kea support subscribers
- [x] 8. For final release - Release Notes should contain changlogs since previous stable release (beta +final)
- [x] 9. Modify Release Notes to Announcement
- fold -sw 73 Kea140betaReleaseNotes.txt > Announcement
- change header
- change ftp links to ww.isc.org/downloads
- send it to yourself to check if it's ok
- [ ] 10. Prepare article on kb.isc.org
- change editing mode to HTML, copy release notes between <pre></pre>
- ask support to publish this document
- [x] 11. Send announcements on:
* kea-users@lists.isc.org
* kea-announce@lists.isc.org
* dhcp-announce@lists.isc.org
- [x] 12. Notify marketing to announce via social media, publish any blog post that is planned
* publish any blog post that is planned
* Update kea.isc.org
* Update Wikipedia page release info
* Add new hooks to downloadable products (if applies)
* Update subscription data sheet with any new hook (if applies)
* Inform sales about what the release may mean to them
- [x] 13. Check KnownIssues list on kea.isc.org https://kea.isc.org/wiki/KeaKnownIssues
- ssh kea.isc.org /var/www/kea-docs
- [ ] 14. update page: https://wiki.isc.org/bin/view/Main/KeaReleaseDates
- [x] 15. update page: https://wiki.isc.org/bin/view/Main/EngineeringReleaseSchedulekea1.7.2Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/1032release 1.7.22019-11-27T03:38:53ZWlodzimierz Wencelrelease 1.7.2---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Process
## Introduction
The Kea release process (for the base version of Kea and the hooks) is different to that of DHCP. At t...---
name: Release Checklist
about: Create a new issue using this checklist for each release
---
# Kea Release Process
## Introduction
The Kea release process (for the base version of Kea and the hooks) is different to that of DHCP. At the moment, Kea has only one supported release at a time, so the process tries to ensure that any modifications needed for a release take place on the master branch, rather than on a version-specific one. The basic steps for a release are:
1) Announce a code freeze for the master branch that will last until actual tarball release
2) Do all necessary changes to the master branch for the release
3) Create release tarball from master branch
4) After sanity checks made by the QA and development teams, either we continue or we accept changes on master to fix issues if needed and go back to the previous step.
5) Create a release branch (for beta) or merge master to existing release branch (for final) and tag release on it. (???)
6) Sign and upload tarballs
7) Announce that freeze time on master branch is over.
8) Release tarballs are prepared by Jenkins job: https://jenkins.isc.org/job/kea-master-tarball-internal/. When given tarball is accepted for releasing it is pushed to repo.isc.org using Jenkins job: https://jenkins.isc.org/job/kea-release-upload-internal/
## Pre-Release Preparation
Some of those checks and updates can be made before actual freeze, but it's reasonable to announce freeze now!
- [x] 1. Check Jenkins results:
* Number of unit tests and system tests failing
* Is there a change in system tests pass rate? *Notify the development team of the overall Jenkins status
* Look into tarball check report " Kea Build Checks" on last tarball build and check if there is nothing suspicious (add/removed files, etc), verify that with developers:
* Compare current release package with code in repository
* Compare current release package with previous release package
- [ ] 2. Is the distcheck passing on kea and kea+premium (https://jenkins.isc.org/job/kea-master-distcheck/)?
* Highlight any issues that require fixing.
- [x] 3. Check perflab if there is no critical errors there (https://perflab.isc.org/)
- [x] 4. Make sure that there is no pending ticket to merge! (Use GitLab https://gitlab.isc.org/isc-projects/kea/merge_requests and https://gitlab.isc.org/isc-private/kea-premium/merge_requests or contact the development team).
- [x] 5. Check the Known Issues list, is there something that suppose to be fixed before release and was omitted?
- [x] 6. Check versioning:
* Ask the development team if the library versions are being updated (there is a step to check it later).
* Ask the development team if the HOOKS_VERSION is being updated.
- [x] 7. Create Release Notes on Kea GitLab wiki using standard template, update all dates and versions. This wiki page should created under "release notes" folder, like this one: release-notes-1.5-final
- [x] 8. Check if there is a Release Checklist ready. If not, create new one using this template (page could have been created, check Releases section at the bottom of this page)
The following steps may involve changing files in the repository. If any files will be updated, create a Kea ticket for them and make the changes on a separate branch.
- [x] 1. Check User's Guide sections:
* Chapter 1. Introduction
- On what platforms we are running tests using Jenkins? Update Supported Platforms
- Did we add any additional 3rd party software? Update if needed
- Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
* Chapter 2. Quick Start
- Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
* Chapter 3. Installation
- Check installation hierarchy
- Check and update Building Requirements
- Check configure options against what ./configure -h says
- [x] 2. Check !ChangeLog entries in Kea main and premium:
* Spelling, missing numbers, trailing whatspaces? (some of that is checked in every build of tarball-internal Jenkins job)
* Update Release Notes with !ChangeLog entries
- [x] 3. Check AUTHORS, INSTALL, README files in Kea main and premium.
- [x] 4. Update information in sources about copyright dates, new version, etc. This is done manually using script https://gitlab.isc.org/isc-private/qa-dhcp/blob/master/kea/build/prepare_kea_release.sh
- [x] 5. Regenerate parsers using docs.isc.org:
* download kea repo
```
cd kea; autoreconf -fi; ./configure --with-log4cplus=/home/wlodek/log4cplus --enable-generate-parser (log4cplus in /home/wlodek should be available for everyone, if not - download your own)
export PATH=/home/fdupont/bin:$PATH
cd ~/kea/src/bin/dhcp4; touch *.yy; make parser
cd ~/kea/src/bin/dhcp6; touch *.yy; make parser
cd ~/kea/src/bin/d2; touch *.yy; make parser
cd ~/kea/src/bin/agent; touch *.yy; make parser
cd ~/kea/src/bin/netconf/; touch *.yy; make parser
cd ~/kea/src/lib/eval; touch *.yy; make parser
```
TODO: we should regenerate all of them or just the one that been modified?
If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the branch to master.
## Build selection and upload package
That is the last moment to freeze code!
- [ ] 1. Update release version in configure.ac and remove -git suffix, and commit the change on master. From that moment all tarball builds can be officially released.
- [x] 2. Go to tarball-internal Jenkins job and pick last tarball build - it will be a release candidate.
- [x] 3. Tarball checks before requesting sanity checks from dev team
* Download tarballs from picked jenkins build
Untar packages:
* Check sizes - is new package reasonable?
* Check installation tree, compare it with previous release
* Check installed lib versions
* which were updated? (save results)
* any of the lib from current release has lower number then corresponding lib from previous release? (!)
* Uninstall Kea, check what left (there should be just configuration files)
* Check if all of installed binaries has man page
* if not, is it in the tarball?
* are man page up-to-date?
* Check if documentation is properly formatted, has correct versions and dates.
* it's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid
- [x] 4. If all seems to be ok then upload tarballs to repo.isc.org
* Go to release-upload Jenkins job
* Click "Build with Parameters"
* In field "Tarball" select picked tarball build
* In field "Release_Candidate" pick:
* rc1 if this is the first selected build for release, it will push selected tarballs to repo.isc.org, to folder suffixed with indicated rc#
* next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in error)
* final if the last rc number was ok, this will push selected tarbal to repo.isc.org, to folder with no suffixes
- [x] 5. If none of the results force you to fix and rebuild package, send sanity check request by an email to dhcp-team@isc.org and qa@isc.org with indicating paths with tarballs on repo.isc.org asking for sanity checks
## Sanity checks proposals:
- [ ] 1. Check documentation:
* users guide:
- dates, versions, installation instructions both for kea and premium, formatting
- if you have time - read as much as you can.
* man pages:
- dates, versions, is it up-to-date? or usage changed between releases?
- does every binary has it's own .8 page?
- [ ] 2. Check tarball content:
* compare tarball against repo (does some of the not included files should actually be included?)
* does premium tarballs include correct hooks? (any missing files?)
- [ ] 3. compile:
* configure warnings?
* build warnings?
- [ ] 4. run unit tests with various db backends, install (check tree), uninstall (check tree)
- [ ] 5. Check example configurations
- [ ] 6. Check release notes (not included in tarball)
- [ ] 7. Check AUTHORS, INSTALL, COPYING, README files
- [ ] 8. Check db update scripts:
* tarball inlcude the last one? (compare with repo)
## Releasing tarballs:
- [ ] 1. Write an email to signers@isc.org requesting signatures of final tarballs on repo.isc.org indicating release folders. - Attach SHA256 checksums from tarball-internal logs.
- [ ] 2. Make release branch (e.g. v1_5_0 one branch for beta and final, with tags for both releases)
- [ ] 3. Upload Release Notes to repo.isc.org
- [ ] 4. When release packages are signed then upload them from repo.isc.org to ftp:
* make-available --public --symlink=cur /data/shared/sweng/kea/releases/1.4.0-beta
* make-available --private /data/shared/sweng/kea/releases/premium-1.4.0-beta/
* make-available --private /data/shared/sweng/kea/releases/subscription-1.4.0-beta/
- [ ] 5. Contact support or marketing to upload packages to www.isc.org/downloads
- [ ] 6. Contact marketing to upload premium packages to 'products' in web store
- [ ] 7. Contact support to deliver premium and subscriber-only hooks to Kea support subscribers
- [ ] 8. For final release - Release Notes should contain changlogs since previous stable release (beta +final)
- [ ] 9. Modify Release Notes to Announcement
- fold -sw 73 Kea140betaReleaseNotes.txt > Announcement
- change header
- change ftp links to ww.isc.org/downloads
- send it to yourself to check if it's ok
- [ ] 10. Prepare article on kb.isc.org
- change editing mode to HTML, copy release notes between <pre></pre>
- ask support to publish this document
- [ ] 11. Send announcements on:
* kea-users@lists.isc.org
* kea-announce@lists.isc.org
* dhcp-announce@lists.isc.org
- [ ] 12. Notify marketing to announce via social media, publish any blog post that is planned
* publish any blog post that is planned
* Update kea.isc.org
* Update Wikipedia page release info
* Add new hooks to downloadable products (if applies)
* Update subscription data sheet with any new hook (if applies)
* Inform sales about what the release may mean to them
- [ ] 13. Check KnownIssues list on kea.isc.org https://kea.isc.org/wiki/KeaKnownIssues
- ssh kea.isc.org /var/www/kea-docs
- [ ] 14. update page: https://wiki.isc.org/bin/view/Main/KeaReleaseDates
- [ ] 15. update page: https://wiki.isc.org/bin/view/Main/EngineeringReleaseSchedulekea1.7.2Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/989update kea version on master2019-11-05T12:00:10ZWlodzimierz Wencelupdate kea version on masteradd '-git' after releaseadd '-git' after releasekea1.7.2Wlodzimierz WencelWlodzimierz Wencel