RFC: Moving Foreman Proxy, Installer and NodeJS to SCLs

This RFC for the Smart Proxy and NodeJS are in progress from a development stand point. Updates will continue to be posted via updates to the top post.

This RFC contains three sub-RFCs but all are related to moving away from system Ruby on CentOS based systems and on to modern Rubies via SCLs. If for any particular one you have further pros, cons or caveats that will need investigating please share so that we have a comprehensive list to work from. Given there are three different sub-RFCs, please all express if any particular order that they are tackled in would be more beneficial.

Smart Proxy

The proposal here is to move all smart proxy packaging on RPM based systems to use the same tfm and thus Ruby SCL that the main Foreman application uses. Today, that would be moving to Ruby 2.5. This work would require

Pros

  • Allow dropping of older Ruby versions in test matrices
  • Use of modern Ruby code
  • Reduces RPM packaging overhead

Cons

  • Pull in and own some EPEL dependencies in our packaging
  • Handling of Facter
  • Will be a package rename for all smart proxy plugins

Installer

The proposal here is to move all of the installer code to be packaged using the SCL on RPM based systems. This would use the same Ruby 2.5 that main Foreman application uses. This work would require:

  • Pulling in some EPEL dependencies
  • Building all installer Ruby packages for SCL
  • Potential updates to load paths for Ruby

Pros

  • Modernizes the installer Ruby code
  • Allows dropping Rubies from test matrix

Cons

  • Untested path for a critical component
  • Pulling in EPEL dependencies

NodeJS [COMPLETE]

This proposal is to move all NodeJS RPM packaging to NodeJS 10 SCL allowing us to drop support for older NodeJS versions. This proposal would involved:

Pros

  • Allows dropping NodeJS 6 in test matrices and development environments
3 Likes

Is this still relevant with RHEL8 / CentOS8 dropping SCLs and switiching to appstreams ?

Good point, isn’t CentOS8 close enough that we would simply delay SCLing and jump on the train of AppStreams? It provides all three mentioned streams, granted the support lifecycle is short but we would probably start to keep up and upgrade earlier.

We’re awaiting CentOS 8 daily. According to the CentOS team, RC work is done and release work is postponed a bit due to CentOS 7.7.

A good question. There are multiple reasons why this is still a good thing to do.

First of all, it’s good to remember that EL7 won’t be dropped directly after CentOS 8 is out. We’ll need time to bootstrap the platform and even then users also need time to migrate. It’s also easier for RHs downstream (Satellite) if EL7 has a bit longer life.

With that in mind, it will be easier to only support modern versions of the languages. Already it’s becoming very painful to use NodeJS 6. We can’t test the UI with it in Travis so we’re at a larger risk of introducing bugs. With Ruby 2.0 that’s not as strong of an issue since our CI still works, but gems are dropping support for it. That means it’s becoming harder and harder for us developers and packagers.

By only supporting modern versions, even on EL7, we also make it easier to use the same package specs for both platforms.

Currently on the facts module uses this. I think we should change it to allow using it as a binary rather than an API.

We do have a rubygem-facter package, but it’s the old version 2. This is used in determining settings, but these could also be determined using built in Ruby functions.

1 Like

Also keep in mind SCL is for parallel installation of the software and appstreams for having multiple versions available but only one installed. So it could be a benefit when everything uses the same ruby version from an appstream, but what about other ruby applications on the system? I do not think there will be unsolveable problems, but as we will not change it for EL7, it perhaps makes sense to wait a while and let us see how others make use of appstreams and what problems appear and how they are solved.

As far as I recall, we don’t support installing foreman on the same system with other apps. Smart proxy would be an interesting case, since in many cases I believe it is installed on the same system as the service(s) it manages.

Please keep in mind discovery image - before we drop it give me echo so I can priorize facter 3+ upgrade.

Copy that. I am fine with SCLing packages tomorrow. It’s just bunch of work, I was thinking if we can avoid it then let’s do it. But you explained it pretty well.

Two of the three RFCs have been started and I will be keeping the top post update to date with status.

1 Like

I experimented with the installer living in the SCL. The issue I ran into has to do with how the SCL environment sets Gem paths, and Kafo and parsers calling puppet through Ruby system calls. When this happens the puppet being called cannot see it’s dependencies.

This is first encountered in kafo_parsers detecting if puppet strings is available. I had two initial thoughts to get around this:

  1. Write code to detect the location of gems and vendor_gems inside /opt/puppetlabs dynamically to allow any version of Puppet AIO to work
  2. Consider packaging the puppet gem directly into our SCL and using that instance of it solely for the installer divorcing it from the use of puppet-agent and puppetserver infrastructure