Feedback Wanted: The Installation Paths we Support as a Project

Community
1

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:

Installation Paths

The current list of supported installation methods according to the Foreman manual:

Installation Platforms

  • Red Hat Enterprise Linux 7
    • x86_64
    • Not tested
  • CentOS, Scientific Linux or Oracle Linux 7
    • x86_64
    • CentOS 7 is tested
    • Scientific Linux, Oracle Linux not tested
  • CentOS 8
    • x86_64
    • Tested
  • Ubuntu 18.04 (Bionic)
    • amd64
    • Tested
  • Debian 10 (Buster)
    • amd64
    • Tested

Puppet versions

  • 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.

Proposal #1

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.

Proposal #2

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.

Proposal #3

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.

2

Hi @ehelms,

With regards to proposal 1 and 2, sounds like a solid plan. I never tried installing Foreman without foreman-installer (even Forklift uses foreman-installer), as all the docs tell you how it works. And dropping untested platforms also sounds like a good plan. Though it might be good to keep an eye on RHEL, as 21% is quite significant.

Proposal 3, I think it’s best (but I am, ofcourse, biased :slight_smile: ) to drop Ubuntu and focus on Debian, which should also cover Ubuntu LTS for the most part (but don’t quote me on this), which are the more stable versions of both distro’s

1 Like
3

One reason why CentOS is the most used os is Katello. Our customers are perhaps evenly spread on distributions for Foreman installations. In most cases it would not be a problem to drop Debian and/or Ubuntu, but I really like that people have the choice as I typically recommend to stay with the distribution the customer knows best. RHEL is not so common as RHEL customers will likely use Satellite instead of the upstream project.

For the direct use of Puppet modules it is more an advanced use case which should be possible but does not need explicitly be supported. At the moment it is mostly used (in environments I know) to setup smart proxies or to split up the monolithic installation on multiple machines.

2 Likes
4

Since we are hopefully heading to deployment in containers, I am all for reducing the matrix as much as possible. That’s what we will do eventually when we solve all issues with containers (it’s all been discussed here at discourse), one platform, run on any OS that supports containers.

I have a problem with the term “support” or “supported” in any kind of open source software. If you call anything “unsupported” that does not stop people from doing things, they still ask and some will not even indicate that the problem you are trying to help with lies in the tiny little detail that it’s highly customized deployment “from scratch”.

Look at the numbers, we don’t have a single sentence (*) about installation “from packages” in our docs, yet almost 40% do this. This is not “supported” as of today. I am all for improving our docs, I think we should focus on streamlining the experience, unifying Katello vs Foreman for once and forever so it’s easier to understand, install or even ugprade.

Yes, I like that. You can’t ask a Red Hat shop to install Foreman on Debian and vice-versa, however asking a Red Hat shop (using e.g. Oracle Linux) to deploy one or few CentOS nodes is not asking much - they probably have the know how.

Yes, I like that to. You can’t ask a Ubuntu shop to install Foreman on Red Hat and vice-versa, however asking a Ubuntu shop to deploy one or few Debian nodes is not asking much - they probably have the know how.

Yeah, I slightly lean towards Debian as this was the distribution I was starting my career with, but I can understand people preferring Ubuntu LTS with it’s more predictable release cadence than Debians’s “when it’s ready!”.

(*) we actually mention how to yum -y install foreman packages, but the rest (99% of the work) is not covered at all :slight_smile:

5

Just to be clear here, there is not a single sentence but rather an entire sub-section of the manual dedicated to this per the first post (and why I call out dropping/re-wording the guide) :slight_smile: – Foreman :: Manual

6

Yeah, this section is being moved to Contributing section. Also it does not mention anything about setting things up, I find it useless and confusing. Development section is much better fit.

1 Like
7

I think I can totally agree with proposals 1 and 2, even tho I disagree with your maths: we don’t have 7 platforms under test, only 4 (CentOS7, CentOS8, Ubuntu 1804, Debian 10). I think we even state somewhere that Scientific and Oracle are not supported. We only would have 7 if we would actually test RHEL/Scientific/OEL.

For proposal 3 I agree that that needs individual testing, but packaging is largely a 1:1 copy, so IMHO not a huge deal. It does produce an increased load during testing (especially release testing) tho. What I like about Debian/Ubuntu is that it forces us to react more quickly to newer Ruby (and other stack parts) versions. Arguably, we would get that if we only supported Ubuntu (or Debian, probably). I think however, that while replacing RHEL with CentOS for the one odd machine is easy, doing so with Debian vs Ubuntu is not – not because the tools are different (they aren’t) but because the release lifecycles are. So I expect users prefer to keep their home-distro of choice.

8

Note, when I did maths and quoted numbers I was quoting supported platforms interpreted by a user reading our documentation. That is, we have a section in the manual 3.1.1 Supported Platforms that lists the 7 platforms. We say quote " Note: The RPM packages are not tested on Scientific Linux or Oracle Linux. The Foreman installation on Scientific Linux or Oracle Linux may or may not work." so we state they are untested but we list them under ‘Supported Platforms’ (hence the proposal to drop them from here). For RHEL 7, we list it, do not test it and do not list we do not test it.

9

I’d be ok with this. If we say, we support the puppet modules used natively as an advanced use case but encourage novice users to use the installer we should cover most use cases and effectively guide users to choose a solid installation method. If users want to use something else (ansible modules, from source, …) they’re on their own.

What would we do with containers?

10

I agree with @lzap that support is always a bit vague and we should avoid the word supported altogether.

I think we should still have reference documentation about how the packages work and how they’re used. This also includes a list of services and config files, but can be limited to core packages. Each plugin can choose to document their packages and config files, but that’s up to the plugin maintainer (or any volunteer). This information is useful in building and maintaining an installer. Advanced users can also use it to install Foreman from packages. However, it should not be in the primary manual. IMHO the installer should be the recommended installation method.

To me open source is about choice and freedom. For this reason I don’t use enterprise software. That’s why I think we shouldn’t treat it as an enterprise software project. Remember that the official support really is you can file a bug report, open a thread on discourse or submit a PR and on none of those there’s any SLA or whatsoever. You only need to have an account to reply so anyone in the community can support it. Today we don’t support containers and yet we know that people run it in containers. To me that’s the beauty of open source.

IMHO we should describe our policy (i.e., we test on CentOS) and let users decide if they want to take those bits and run it on RHEL. We can even provide some instructions (as we do today) to enable the correct repositories.

As @evgeni said: a lot of the push to support new software comes from trying to support the latest Ubuntu. We were already very late with EL8 support so I’d be worried about stagnating and becoming enterprise software that requires very old versions.

To me there really isn’t a difference between Debian and Ubuntu since they’re similar enough so to me the proposal doesn’t make a lot of sense.

However, it is concerning that we currently don’t have a real maintainer for the packages. That’s why I’d say the choice is currently between Debian+Ubuntu or neither.

1 Like
11

While I agree that we should clearly state that “we test on CentOS”, which is a good communication towards users so they can really realize if they want to go the easy or the difficult road, I think we should be also honest to us: if we don’t test it, how can we possibly maintain documentation that will not break?

For this reason I think it’s a good idea to drop it for those who would not read our statement about testing carefully and just quickly scan the document for “relevant” info. I know people do this because I do this myself, blah blah, skip this, where the heck is the command I can paste to my terminal…

12

Well, someone, somewhere, said that all those EL distros should be (bug)compatible :wink:

More honestly, we probably just should provide exact instructions for CentOS and for everything else state something like “You will require the Red Hat provided Software Collections for Ruby, PostgreSQL, Redis to be available” and don’t tell them how to enable these (there are probably more places that need similar wording adjustments).

2 Likes
13

Does it make sense to link to some discourse tutorial to make it easy for the community to maintain and support?

14

We are pretty successfully to use Oracle Linux 7 and probably also 8 as the base system on which foreman/katello is installed. The reason for this is:

  • oracle is more “up to date” regarding security fixes than CentOS. Updates for CentOS8 - even security updates, are released “days/weeks” after they are available for Oracle8
  • for CentOS7 it was possible to “generate” Errata information. For CentOS8 this is no longer possible - even with scripts like http://cefs.steve-meier.de/
  • Oracle7 works pretty good with foreman / katello as its compatible with CentOS7 / RHEL7. Pretty sure (ok, I hope it) this will be the case Oracle8, too.
1 Like
15

That’s good to know, but: we as a project don’t (and don’t have the bandwidth to) verify the builds work on Oracle (or anything but CentOS), and that’s why I said above “it should work, and we should document it should work, but still say, we don’t guarantee it” (rephrased).

1 Like
16

I agree with proposal 1 and 2, seems like majority in this thread does. For proposal 2 I think people lean to document as known to work but genenrally untested.

For proposal 3, I see @ekohl’s concern and I think we should seriously consider dropping debs. I tried to describe the plan for this at Future of debian packaging. I see this can be a complication for Debian/Ubuntu shops, Hopefully they could then contribute their knowledge and help us with packaging.