High level requirements are located in Kea 1.6 charter. User complaints about Kea installation are gathered here.
Kea supports many optional environments. Some of them are easy set up (MySQL, PostgreSQL), but others are not. Cassandra packages are often outdated in distros and installing packages from cassandra.apache.org is required. Furthermore, we need a cpp-driver (a C++ interface for Cassandra), which is available on github only. The second tricky environment is RADIUS. We use a FreeRADIUS client patched by Francis. The third and by far the most difficult environment Kea can work with is NETCONF. It requires Sysrepo, which has many dependencies that are not packaged even on popular OSes such as Ubuntu. The compilation is far more complicated than configure && make. See netconf install notes on Ubuntu for example.
On top of that, we have a number (8 in kea 1.6) of paid hooks. The number is increasing with every release. We want to give people an easy way to install them. In Kea 1.5 the only way to compile hooks was to extract kea sources, extract hooks package into premium/ subdir and then recompile everything.
Requirements for Packages
Kea packages content
Kea modules and extra features should be packaged separately into dynamically loaded libraries, see more in #435.
packages should be prepared in a way that allow installation and upgrading
coordinate packaging with distro maintainers
keep solution close to distros solutions so maintainers could gain from packaging changes on Kea side and quickly update their side when something changes in Kea e.g. new daemon has been added, etc.
our list of packages should take into account #435 so mysql is plugable as package, etc.
our package names should be different to avoid mixing
our packages should be in conflict with distro packages so it should not be possible to install both at the same time
note: extra packages for 3rd party dependencies not available as packages e.g. NETCONF
packages should be compliant with distros policies
Kea processes should use native solutions for services, systemd on Linuxes, daemon on FreeBSD
distributing open source packages and premium/subscription packages should be supported
packages should be exposed as just a folder of files on FTP/HTTP server
all types of packages should be served from one location if possible
packages should be exposed via native repositories e.g. generated deb/rpm repository, so they can be added to distro in /etc/apt/sources.list or /etc/yum.repos.d/ and installed by apt or dnf, eg. using Nexus Repository OSS from Sonatype
repositories should be signed
rpm packages should be signed
access control should be applied to premium and subscription packages
there should be 2 flavours of repositories:
release repos for keeping all release packages
CI/engineering repos where packages will be added after each successful CI build
Requirements for Repository Hosting Solution
different package formats: rpm, deb, docker (in the future)
public and private repositories
fine grain access control (selected packages can be accessed by selected customers)
release repositories with content uploaded infrequently
CI/engineering repositories where content is uploaded several times a day
creating customer accounts, giving and revoking access to repositories
API for creating accounts and for giving and revoking access
kea-1.6-ubuntu-18.04 - repository for released packages for 1.6 branch for Ubuntu 18.04
kea-1.7-centos-7 - repository for released packages for 1.7 branch for Centos 7
kea-1.8-freebsd-12-ci - repository for engineering packages, not yet released for 1.8 branch for FreeBSD 12
Premium Packages in Repos
Premium packages in repositories are protected by defined content selectors. All the packages in given repository are public but the ones indicated by content selector which have premium word in their name. These premium packages are only visible to logged in users with given permission.
We should also assess whether we can use this repo for the premium sales from the web site. Currently we do this by uploading the package to the 'store' and having the store handle the downloading, but as we will have more OS options, it would be better to use this repo directly.
We also need to have a way to give prospective new users a 'trial copy' (done via sales). For this we can create a dummy user account and just change the pwd periodically.
If the repo can email registered users when a new version is uploaded, that would be a very useful feature.
We need to check the user account creation and pwd reset - it is probably ok, but this is a significant usability and supportability factor. Do we want accounts for each individual user (e.g. 6 * number of support customers), or shared 'customer' accounts?
It is useful to be able to see downloads by time period, and version. This enables us to see what is the most popular version and to see when the bulk of users have updated to a new version.
We don't want people logging issues against the packages in the package system, do we? It would be good if we can configure in links to the relevant Gitlab projects.
Synchronization with Distributions
Kea is being tested on:
FreeBSD 11.3 ???
Fedora 28 - supported till 2019.06
Fedora 29 - supported till ~2019.12
Fedora 30 - planned release on 2019.05.07, will include Kea ???
Old release X is maintained until 1 month after the release of X+2.
RHEL 7 - End of Full Support: 2019 Q4, End of Maintenance Support 2 - 2024.06.30
RHEL 8 - beta released on 2018.11.14, planned release on ~2019, will include Kea ???
Releases 1 month after RHEL releases. Support is the same as in RHEL.