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
Updating of all smart proxy packages and plugins to have SCLized specs
Pulling in EPEL dependencies and building them for SCL
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
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.
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.
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.
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:
Write code to detect the location of gems and vendor_gems inside /opt/puppetlabs dynamically to allow any version of Puppet AIO to work
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.
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.
