Path to Ruby 3.0, 3.1, EL9 and Ubuntu 22.04

Development RFCs
7

I’ve created a GitHub project as a way to track the progress:

This is the first time I’m trying an organization wide project, but I hope it’ll be useful.

2 Likes
8

Nice summary of the work required.
Geezus christ though, what a lot of ballache.

Why in hell does EL9 not just provide a ruby 2.7 in addition to the Ruby 3, for christ’s sake.
Pathetic, that Red Hat does not care enough about backward compatibility, and its customers, to do this. It should not be difficult to have Ruby 2.7 and 3 on same server.

9

Quite simple, as Ruby 2.7 is EOL. Better pushing resources to move forward than to support something EOL. But this only my opinion!

2 Likes
10

Ruby 2.7 EOL is no excuse
Windows can still run binaries from Windows 95.

And last time i checked, I could still run Orbital Eunuch Sniper and Quake 3, on linux, and those games are now several decades old.

Just because Ruby 2.7 goes EOL doesn’t mean everything written in Ruby 2.7 is thrown on the scrapheap. And if it does mean that, then the question must be asked,why do people write anything, in these poorly support products that are going to disappear in a few years with no effort made by anyone to maintain backward compatibility.

Even if Ruby 2.7 is EOL there should be a ruby 2.7 legacy or compat package so things that require it can continue to function properly.

11

Hello. Looks like there’s “only” the Rails 7 & Ruby 3.1 task left on “Ruby 3 support” project tracker. Any idea what version of Foreman is targeted for initial el9 support, or is that too far off in the future to tell?

12

It’s hard to commit to any version.

@akumari has done a good job on making sure the Smart Proxy is tested with Ruby 3 in our CI. While it’s not acceptance tests or full system integration, it is a solid base layer.

As for Rails, it’s less positive. While my PR (Rails 7 & Ruby 3.1 by ekohl · Pull Request #9328 · theforeman/foreman · GitHub) might give the impression it’s close, that’s only the start. Once we have Zeitwerk working in Foreman itself, we must also make sure all plugins work with it. That hasn’t even started so who knows which dragons lurk there. I’m trying to work with @ofedoren and @akumari to make progress, but given where we are I wouldn’t expect it in Foreman 3.9.

For EL9 we also need to tackle our NodeJS update, which implies a webpack update. @MariaAga has submitted https://github.com/theforeman/foreman/pull/9834 which is a leap forward. Resurrection of the client-side infrastructure upgrade effort is also tracking that. AFAIK that has been tested in developer environments, but is now in review and packaging also needs to be done. Given its current status this has the potential to make it into Foreman 3.9.

2 Likes
13

Thanks, @ekohl . Appreciate the update.

14

Today @akumari and @ofedoren discussed the Rails part. Essentially we have this dependency chain:

EL9 needs Ruby 3
Ruby 3 needs Rails 7 and other gem updates
Rails 7 needs Zeitwerk

So we first want to focus on the Zeitwerk migration. It’s something we can start shipping with our current Rails 6.1 stack.

Once core is compatible with rake zeitwerk:check that will be added to our CI pipeline to prevent regressions.

It may break a lot of plugins if we just switch core, so we want to introduce a setting in settings.yaml so you can switch it. Once the full test suite passes with it, the CI test suite will be expanded to run it with both the legacy and modern loader. At this point we’ll push plugin developers to make their plugins compatible. The setting can also be switched in production builds, so full end to end testing can be done. We may also introduce an additional pipeline in our nightly runs to do so every run.

Compute resources don’t have automated end-to-end coverage so will need manual verification.

This is something we want to reach for Foreman 3.9. The default isn’t switched yet, but be ready. Then give plugin developers some time to do the same. Shortly after we branch and develop becomes 3.10-develop, we will switch the default.

Then we spoke about future steps. With Zeitwerk in place, we can start Rails 7. It’s unknown how many issues we will find. If all goes well, we should target it for Foreman 3.10.

Even further in the future is Ruby 3 itself. At this point I’d say that Foreman 3.11 may be optimistic, but I’d like to target Foreman 3.12.

As always: these are intentions and no hard commitment. Most of us know how messy these things can be and you always find dragons.

We’ve agreed to meet up weekly and for now I’ll keep posting the updates here.

Short term @ofedoren will look at my Rails 7 PR and see which Zeitwerk parts he can take over and possibly already merge. @akumari will look at the fast_gettext update in there, which is needed for Ruby 3.2 support.

3 Likes
15

I’m curious what drives this requirement? Rails 6.1 doesn’t run against Ruby 3?

16

I tried to look for official support, but these guides don’t explicitly say “now it runs with Ruby x.y”. I looked at:

Rails 7.0.1 was at least the first one to support Ruby 3.1 (Ruby on Rails — Rails 7.0.1 has been released), which is included in Debian 12. It’s also the first one to say Ruby 3.0+ preferred. So perhaps it’s based on an assumption on my side.

But you’re right. Ruby & Rails Compatibility Table - FastRuby.io | Rails Upgrade Service states that is recommended to run on Ruby 3.0.Z. I suppose I when I started, I was very focused on getting it to run on my Fedora which included Ruby 3.1.

That does change the dependencies a bit and allows for more parallelization.

2 Likes
17

As promised, I’m summarizing our weekly sync up here.

We briefly discussed the possibility to run Rails 6.1 with Ruby 3. @ekohl will look at introducing expanding the Foreman Jenkins job to start testing on Ruby 3.

@ofedoren noticed that openscap_parser started to require Ruby 3, though that may have been a mistake (fix: RHICOMPL-3900 disable required ruby version rubocop check by marleystipich2 · Pull Request #56 · OpenSCAP/openscap_parser · GitHub).

@ofedoren is wrapping up some other work before he can start investigating the Zeitwerk status

@akumari is investigating the update to fast_gettext.

3 Likes
18

And another weekly sync up.

4 Likes
19

Due to people having time off we didn’t have the regular sync up, so it’s been a bit quiet on the updates. That doesn’t mean no work has been done.

@ofedoren has been working on testing Foreman with Ruby 3 in CI (Fixes #36849 - Set up CI with Ruby 3.0 by ofedoren · Pull Request #9871 · theforeman/foreman · GitHub). We’ve decided to split this up into two parts: one part that adds GitHub Actions based testing with the current status (Ruby 2.7). The follow up will add Ruby 3.0 to the testing matrix. @ekohl will write up a separate RFC on this topic so it’s also clear what the plan for plugins is. This RFC is already big enough and it would get lost here.

While testing @ofedoren ran into Fix possible nil volumes for libvirt by ofedoren · Pull Request #133 · fog/fog-libvirt · GitHub and @ekohl will do a release of fog-libvirt. That’s useful anyway because there are unreleased changes that bring compatibility with modern libvirt as included in EL9 (Set the default machine type to q35 on i686 and x86_64 by ekohl · Pull Request #127 · fog/fog-libvirt · GitHub & Fix disk type for block devices on QEMU >= 6.0 by ekohl · Pull Request #129 · fog/fog-libvirt · GitHub).

@akumari has been moving forward with the apipie-dsl translations. While no longer a blocker to upgrading, https://github.com/theforeman/foreman/pull/9867 is still a nice step forward.

@akumari has also started to look at updating GitHub - theforeman/theforeman-rubocop: Foreman RuboCop basic rules to the latest version and making it the recommended Foreman & Foreman plugin RuboCop configuration. This is useful because there are various cops that help with the Ruby 3 upgrade (Lint/DeprecatedClassMethods being the most obvious, but there are more).

5 Likes
20

Another week, another update.

First of all, @evgeni and @ehelms will try to assist in the effort. We took a look at the overall structure of the project to try and divide tasks.

Taking a high level overview, we can identify a few subsystems (assuming a full Katello installation):

  • Foreman
  • Foreman Proxy
  • Hammer
  • Pulp
  • Candlepin

For simplicity, I consider plugins part of the subsystem.

Broadly speaking we consider some subsystems ready for EL9, but sometimes untested. Foreman Proxy, Hammer, Pulp & Candlepin all should work but most of the readers will know that theory and practice don’t always agree.

@evgeni wants to get started on packaging effort for those already (and Pulp is already done). So EL9 yolo by evgeni · Pull Request #9990 · theforeman/foreman-packaging · GitHub is the first kick off for that.

For Foreman we still have quite a bit of work to do and that’s what we’ll continue to focus on. As mentioned previously, the whole CI setup needs an overhaul. Foreman has long used Jenkins, but it needs an update. I’m preparing a separate RFC for that, but the summary is that we want to use GitHub Actions.

We also made sure Ruby 3 support · GitHub was updated.

2 Likes
21

Today’s meeting wasn’t very eventful and we only made sure Ruby 3 support · GitHub was updated and everyone was in sync again.

@akumari is picking up an update of theforeman-rubocop. This is not just updating the gem versions, but also looking at cops which make sense to enable. In addition to that, verifying Kafo works on Ruby 3 & Puppet 8.

@ofedoren was on PTO, but we have merged Fixes #36913 - Set up GHA with matrix to run test on Ruby 2.7 by ofedoren · Pull Request #9900 · theforeman/foreman · GitHub.

@evgeni is moving forward with packaging: Build Rails for EL9 by evgeni · Pull Request #10015 · theforeman/foreman-packaging · GitHub

@ekohl finally finished the RFC he promised: Convert Foreman & plugins continuous integration to GitHub Actions

3 Likes
22

Since last week there’s been a lot of progress for GitHub Actions in foreman.git (History for .github/workflows/foreman.yml - theforeman/foreman · GitHub) to the point that once also execute assets:precompile as part of GHA tests by evgeni · Pull Request #9940 · theforeman/foreman · GitHub is merged, the coverage should be the same as in Jenkins. An issue has been opened to get the reusable workflow to the same level of coverage: Bring back changes from Foreman core's workflow to foreman_plugins · Issue #23 · theforeman/actions · GitHub

Reviews on safemode PRs (Support safe call by ekohl · Pull Request #46 · theforeman/safemode · GitHub & https://github.com/theforeman/safemode/pull/44) were done. Due to travel and PTO @ofedoren may take over the effort from @ekohl.

The PR to build packaging on EL9 (Build Rails for EL9 by evgeni · Pull Request #10015 · theforeman/foreman-packaging · GitHub) has been discussed. The approach is to create a new config in COPR that has both EL8 & EL9 chroots, so it can build them in parallel. We can then bootstrap the platform by moving groups over, in the correct order. It will be good to keep notes since we’ll apply the same thing once EL10 comes around the corner.

Next week’s meeting is cancelled because most people have other obligations.

2 Likes
23

Due to travel and time off I haven’t been here for the past 2 weeks, but today we synced up again.

@ofedoren has released a new version of safemode that is compatible with Ruby 3.0. Foreman still needs to be updated (included in https://github.com/theforeman/foreman/pull/9871).

@evgeni has made a lot of progress packaging large parts on EL9. Next steps are to build the Smart Proxy plugins and publish the packages on yum.theforeman.org so we can start updating our Puppet modules to also test it.

@akumari has also been traveling and had time off.

3 Likes
24

As every year, Ruby has released a new version over Christmas. Ruby 3.3 appears to be small in terms of breaking changes. While reading up on it, I noticed that Ruby 3.0 is EOL in March 2024, so in 3 months. I’d still go forward with releasing it on EL9 on 3.0, even if it is EOL because Ruby 2.7 is already EOL since March 2023 anyway and that hasn’t held us back.

3 Likes
25

Today we synced up again after we’ve all been out for the holidays. Some updates since last time.

Foreman

Foreman has been updated to use safemode 1.4.0, including tests that verify the new safe navigator operator in templates (Fixes #37010 - Support safe navigation operator in safemode by ekohl · Pull Request #9967 · theforeman/foreman · GitHub). Some safe changes for Ruby 3 compatibility have been merged (Refs #36849 - Ruby 3 preparations by ekohl · Pull Request #9975 · theforeman/foreman · GitHub).

This leaves the Ruby 3 enablement with a more controversial change. Both Fixes #36849 - Run GHA on Ruby 3.0 by ofedoren · Pull Request #9871 · theforeman/foreman · GitHub & Fixes #36849 - Run GHA on Ruby 3.0 (alternative) by ekohl · Pull Request #9923 · theforeman/foreman · GitHub try to deal with the method_missing change. @ofedoren will look further into this. @ekohl has submitted an update to clarify the Ruby docs as well (Improve method_missing method documentation by ekohl · Pull Request #9412 · ruby/ruby · GitHub).

@ofedoren will start looking at testing plugins. test with ruby3-compatible foreman by evgeni · Pull Request #24 · RedHatSatellite/foreman_theme_satellite · GitHub is the way for plugins that use our reusable GitHub Action.

Packaging

On the packaging side some progress has been made:

With all of these changes we’re close to publishing el9 nightly repositories (enable nightly el9 repo generation, closure and publishing by evgeni · Pull Request #395 · theforeman/jenkins-jobs · GitHub). Just need add plugins el9 copr config and comps by evgeni · Pull Request #10200 · theforeman/foreman-packaging · GitHub. Then el9 should show up on Index of /foreman/nightly & Index of /plugins/nightly. Support EL9 by ekohl · Pull Request #823 · theforeman/puppet-foreman_proxy · GitHub was opened to test this, but we quickly found that the repository layout of stagingyum and yum differs.

CI

To support testing Katello (which relies on postgresql-evr) the PostgreSQL container image has been made a parameter (allow configuring postgres container image · theforeman/actions@b663142 · GitHub & also allow custom DB container for DB job · theforeman/actions@e4e8fb7 · GitHub). https://github.com/Katello/katello/pull/10780 uses this with @evgeni’s fork. also release container to GH registry · Katello/postgresql-evr@b79100d · GitHub has been merged, but it hasn’t ran yet.

Install NPM packages & compile webpack by ekohl · Pull Request #18 · theforeman/actions · GitHub has been updated and needs a review. @ekohl will take a look.

Add Ruby 3.0 + Puppet 7 & 3.2 + Puppet 8 to CI by archanaserver · Pull Request #369 · theforeman/kafo · GitHub was merged.

New discussion items for next time:

  • How to install test dependencies? Today Jenkins for regular plugins uses gemfile.d/*.rb and our reusable actions do the same, but Katello has a special job in Jenkins that installs it as a gemspec, which installs all development dependencies. This came up in https://github.com/Katello/katello/pull/10780.
  • Today Katello’s tests run on every Foreman PR using Jenkins. Should this be ported to GitHub Actions?

Updating RuboCop

https://github.com/theforeman/theforeman-rubocop/pull/8 is in progress. PRs to various repositories are being opened to prepare for an update:

2 Likes
26

Another week, another update.

Major milestones are around packaging. @evgeni has started to push out Smart Proxy & plugin packages. The Puppet module for foreman_proxy already passes its test suite (Support EL9 by ekohl · Pull Request #823 · theforeman/puppet-foreman_proxy · GitHub) so we can at least say that various packages install and the service starts. Work continues by doing the same for content proxies (Support EL9 by evgeni · Pull Request #469 · theforeman/puppet-foreman_proxy_content · GitHub). That’s green, so once the Katello packages have been published (add el9 to katello repository generation/publishing by evgeni · Pull Request #403 · theforeman/jenkins-jobs · GitHub) it should be good to go. Those test suites are limited in testing the actual functionality, but are a solid foundation to build on. allow overriding the server/proxy OS by evgeni · Pull Request #1752 · theforeman/forklift · GitHub allows spinning up an EL8 Foreman server with an EL9 content proxy. There @evgeni has found some functionality that doesn’t work (like SELinux issues), but things are coming together.

In doing this work it was a problem because foreman-debug and katello-debug need to Foreman to be built. Instead we’ve made those optional (Drop requirement on foreman-debug by evgeni · Pull Request #10187 · theforeman/foreman-packaging · GitHub Don't require katello-debug by evgeni · Pull Request #10257 · theforeman/foreman-packaging · GitHub do not install katello-debug by default by evgeni · Pull Request #468 · theforeman/puppet-foreman_proxy_content · GitHub). The functionality should be in sosreport so this also allows slightly smaller installations for end users.

On the Foreman side @ofedoren has started to properly analyze the issue we had. Run GHA on Ruby 3.0 (alternative 2.0) by ofedoren · Pull Request #9989 · theforeman/foreman · GitHub uses the same constructor method signature that Rails’ activerecord has so it’s promising for a proper fix.

Other than that Install NPM packages & compile webpack by ekohl · Pull Request #18 · theforeman/actions · GitHub was merged so now Foreman plugins should get good test coverage when they use the reusable action. That is now a significant milestone in Convert Foreman & plugins continuous integration to GitHub Actions - #4 by ekohl. @akumari has started to expand our investigation in Verify it works with all plugins · Issue #1 · theforeman/actions · GitHub, but even that is still incomplete. @ekohl will put out a call to plugin maintainers to collaborate on this.

One remaining issue that shows up in most plugins is running of tests from Foreman core in a plugin (always execute access_permissions_test from Foreman core by evgeni · Pull Request #16 · theforeman/actions · GitHub). This isn’t an issue in Jenkins, because that runs the entire Foreman test suite (to prevent regressions). GitHub actions only runs the plugin’s but some do run some tests from core. This needs a resolution for plugins using GitHub Actions today.

Another that came up is installation of chromedriver (Rewrite GHA workflow using reusable actions by archanaserver · Pull Request #381 · theforeman/foreman_puppet · GitHub). It’s unknown how Foreman itself does this today (it doesn’t install Chrome, so does it even run at all?). There’s also a PR open for a remote webdriver (Fixes #36978 - Add possibility to use remote webdriver by dosas · Pull Request #9952 · theforeman/foreman · GitHub) which may allow us to use a webdriver container and connect to that instead.

To know how far we are in the migration it would be good to add CI descriptions to Foreman landscape and @evgeni will take a look.

It also came up that we may want a reusable action for Smart Proxy plugins (add proxy plugin workflow by evgeni · Pull Request #27 · theforeman/actions · GitHub) but that’s considered low priority now.

Lastly, it’s noted that we will need to deal with the webpack update (https://github.com/theforeman/foreman/pull/9834) if we want to run on EL9. @ekohl will reach out to @MariaAga how we can get that merged as soon as possible.

1 Like