With Rails 6 around the corner, it is time to start planning our upgrade to it. In the past major Rails version upgrades took a lot of effort, and there are other considerations as well that are needed to be taken into account. During the meeting in Brno, we had a small working group (@kgaikwad, @shiramax, @evgeni and myself) to try and map the steps needed to get to Rails 6. Below are the outcomes of our discussion, feel free to chime in with your opinions and suggestions.
Rails 6 has two requirements which also need to be taken into consideration:
- The minimal supported Ruby version is 2.5. This means that when we move to Rails 6 we will need to drop support for Debian Stretch and Ubuntu Xenial which ship with Ruby 2.3.
- The minimal supported PostgreSQL version is 9.3. CentOS 7 only ships with 9.2, which means we will need to either migrate to an SCL version of PostgreSQL for CentOS 7 or drop support for it and require CentOS 8 as a prerequisite (which ships version 10 by default). We will likely need to upgrade PostgreSQL version in any case during this timeframe to support Pulp 3 in Katello - as it requires PostgreSQL 9.6 at least.
We have outlined the following proposed stages to get migrated to Rails 6 in a gradual manner so we can avoid having a huge PR with all changes that will need to be constantly rebased:
- We are currently running on Rails 5.2.1, while the latest version is 5.2.3. During the 1.23 time-frame we should be upgrading to the latest 5.2 version so we don’t need to fix changes needed for it while working on the 6 upgrade. The tasks needed to be done for this are tracked in https://projects.theforeman.org/issues/25601 (thanks @mmoll!).
- In 1.24 we should get all of the backwards-compatible changes that are needed for Rails 6 compatibility, and ideally with as many backward-incompatible changes already included behind guard conditions. We will use a similar setting as we did for the rails 5.2 upgrade to allow for working with both versions. The tasks needed for Rails 6 compatibility are tracked at Tracker #24837: Rails 6.0 Tracker - Foreman (thanks again @mmoll!).
- Once initial changes are ready, we will enable testing with Rails 6 on CI without making it fail tests, to ensure no new Rails 6 incompatible changes are added and indicate the progress on this effort.
- As we identify the needed changes, we will create a guide for plugin authors indicating steps needed to ensure compatibility.
- During this time frame we should also look into the steps needed for upgrading to PostgreSQL 10 using SCL on Centos 7. Some insights can be gained from the process done to migrate MongoDB from system default to SCL for katello. We thought if we are going to need scl anyways, it would be beneficial to standardize on the same version that will be in Centos 8 and is already in all Debian-based distros. PostgreSQL 10 also offers some significant improvements with regards to performance.
- 1.25 will ship with only Rails 6 enabled. This means that the supported distros will be Centos 7 and 8, Debian Buster (10), which should be released by then, and Ubuntu Bionic (1804). If all goes well, 1.25 should ship around February 2020.
- Is it reasonable to expect debian stretch and ubuntu xenial users to be able to upgrade their base OS in this time frame (about 9 months)? If not, should we postpone the upgrade to allow a longer timeframe for upgrades?
- What is the supported life of the PostgreSQL 10 SCL? Will it be long enough until we can completely drop CentOS 7 support or will we be stuck with an unsupported SCL or have to build our own?
- Would it be better to not try supporting Rails 6 on CentOS 7? This would save the effort of having to handle upgrades from system packages to SCL during the upgrade. On the other hand, this may delay the Rails 6 upgrade, require dropping CentOS 7 support earlier, and/or delay Pulp 3 adoption in Katello.
- We will need to make sure Candlepin can also work with PG 10.
- Who is going to be involved in this effort? I agreed to coordinate it, but this will likely require help from more developers, including at least one from the @packaging team.
- What did we miss? There are certainly other things we did not think of that may affect the proposed plan.