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


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


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


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


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


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


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:


  • Allows dropping NodeJS 6 in test matrices and development environments

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

Posting an update regarding the SCLing of Foreman Proxy. The work for this has all been approved and the packaging parts merged. Pipelines will be running along with installer updates over the next day. I will report back once this work is complete. I encourage all smart proxy plugin authors to test the new plugins on an EL7 installation once we are done.


Thanks, once proxy will be ready in nightlies give us a shout and I am gonna try it out.

Foreman nightly and Plugins repository have been updated with Foreman Proxy built against SCL and all plugins as well. Plugin maintainers are encouraged to test their plugins and the new packaging on EL7.

1 Like

Thanks for the heads up, FDI changes done and it works fine: https://github.com/theforeman/foreman-discovery-image/pull/121 and I am going to initiate new nightly build so users can start testing it.

Since Foreman 2.1 all of the mentioned projects run on SCL (which means Ruby 2.5+) and we can consider this done.