This is a mixture of looking for feedback from the user community and providing a proposal for what the Foreman community officially supports as installation paths looking ahead. One of the goals with this discussion is to narrow the set of supported paths to enable developers to focus on making those paths more robust, and build new features while working to support the most popular methods that users use today. Given the size of our developer community, I think it is practical for us as a community to explore what installation methods we support and focus that matrix.
From our documentation, summarizing the installation paths, platforms and puppet versions for installation where paths involve using puppet:
The current list of supported installation methods according to the Foreman manual:
- Packages only, self configured
- From source, self configured
- Puppet modules, not listed in manual
- Red Hat Enterprise Linux 7
- Not tested
- CentOS, Scientific Linux or Oracle Linux 7
- CentOS 7 is tested
- Scientific Linux, Oracle Linux not tested
- CentOS 8
- Ubuntu 18.04 (Bionic)
- Debian 10 (Buster)
- Puppet 5
- Puppet 6
This gives us, if my math is correct:
(7 platforms * 2 puppet versions * 2 puppet methods) + (7 platforms * 2 non-puppet methods) = 42 supported installation paths
That is a lot of paths to test, and in reality, we only test a subset of these combinations and we only test them at certain levels. For example, we do not test Scientific Linux or we do not test the foreman-installer itself on Puppet 5 but the individual modules that make up the installer are tested against Puppet 5.
Looking ahead, Puppet 5 will EOL but Puppet 7 is likely to be available around a similar time frame thereby keeping two Puppet versions at all times. Which, depending on the amount of change between each major release can lead to further support burden.
Looking at our most recent (2020) community survey, a breakdown by platform:
- CentOS: 48.1%
- RHEL: 21.5%
- Debian: 12.6%
- Ubuntu: 7.5%
- Oracle: 3%
And a breakdown by installation method:
- Foreman installer: 45%
- From packages: 39%
- Puppet modules directly: 4%
As noted in the previous section, our manual includes a section on ‘From packages’ which implies manual configuration but does not preclude the use of the Foreman Installer or Puppet modules directly and may be a source of confusion for users filling out the survey.
If we look at OS in use, we actively test CentOS installs on a nightly basis but do not test RHEL we are supporting by implication given CentOS is a downstream of RHEL. For Ubuntu and Debian we support two OSes at two different versions and available stacks that are actively tested on a nightly basis. However, we currently lack any active maintainers of the Debian packages.
The following proposals are only potential ideas, and not mutually exclusive options (we can choose to implement any number between 0 and 3 of them). They should be considered my initial ideas from the available data, my experience in the community and conversations with developers and users. These are merely proposals and not binding. And do not reflect any actions the project is already planning to take. There are other options that we should explore and I encourage users and developers to bring them to the conversation for inclusion.
Move to a model where the only officially supported installation method is through the foreman-installer. This would focus development on the foreman-installer, and the puppet modules that back it. Further, this will aid in the effort to unify Foreman and Katello (arguably the largest plugin within the ecosystem) installation paths and the experiences that users have. This change would help reduce the matrix of paths that users take when installing or upgrading and hopefully enhance community support from developers or other users. This proposal would come with a rebuild of the installation manual to create a directed, step-by-step guide to install. For the modules direct use case, since this is a small percentage of the user base, we would include a note about them in the manual that indicates that should be used directly only if you know what you are doing as an advanced use case.
Drop untested platforms from official support. At the present this would mean dropping the following: Scientific Linux (discontinued), Oracle Linux, and RHEL 7. This change would allow our manual and our focus as developers to be on the platforms we actually test rather than providing users with vague support. Users can rely on what we list as supported platforms as those that are tested, can expect bug fixes and official support through forums when users run into issues.
Support Debian or Ubuntu, but not both. According to the survey, these two platforms account for 28% of our install base which is not insignificant, but each requires their own support, packaging and deployment considerations. The software versions available on each varies and increases our testing matrix. When we consider that 30% of the install base is using RHEL, which we do not test against, having two OSes that almost meet that combined behooves us to consider dropping one to reduce our overall support matrix. This would allow us to focus on supporting a single stream of apt-based package system. Further, we currently have no active maintainers of the Debian packages which implies that deployment mechanism will suffer from software rot over time.