Upgrade ruby version to 2.4.2

[shirshendu]

Ruby 2.0.0 has been EOL since 24th Feb 2016 (https://www.ruby-lang.org/en/news/2015/12/16/ruby-2-0-0-p648-released/). We need to move the project to a later ruby which is maintained, and yet keeping the project possible to install just as easily on a fresh RHEL/CentOS box.

My current thoughts for going about this would be to bump the ruby version in our project to 2.4.2, and add installation guidelines, depending on RHSCL - rh-ruby24. (https://www.softwarecollections.org/en/scls/rhscl/rh-ruby24/)
The main concern here is, would downstream deployments be open to depending on (potentially) an additional channel?
What are the constraints that downstream deployments are working with? Open to alternative suggestions.

Updates would possibly be required to the README, service file, Tendrl/ansible (add SCL repo, ruby2.4.2 installation), and maybe even the copr build process (but need to verify that).

[TimothyAsirJeyasing]

Sure, we can work on this issue for downsteam as well. We may need to verify and update each dependency gems of tendrl.

[mbukatov]

The primary factor here is that we are building on top of RHEL 7 operating system (one can deploy on CentOS 7 as well, but this is the same system from developer's point of view). Which means that we should work with packages available in RHEL.

Now you have a good point with the ruby 2.0.0 EOL, but RHEL 7 will be supported for much longer time frame, which means that maintenance of ruby is not our (tendrl devel team) problem.

The approach with software collection is a good one, but it doesn't fit our use case:

• The support of software collection is short (few years) compared to RHEL (10 years and more if you pay extra money), and has different life cycle compared to RHEL, GlusterFS and Tendrl. This means that we would need to track changes in the collection, retest and make updates if needed.
• In downstream, using the collection would require a separate subscription.
• It would make the packaging more complicated for us, as all ruby packages we have in our dependencies repository would need to be packaged as software collection, which is a subcollection of the ruby 2.4 collection. Moreover this could mean maintaining much larger set of ruby packages compared to what we have today, because the ruby collection contains only minimal set of packages compared to what is available in rhel repositories.

I believe that software collection would make sense for rhel/centos users who want to build and maintain their own ruby apps using different ruby version for themselves.

But for us, this seems like a lot of work and additional complexity, especially when we consider that the api is only one component from many we have. I would say that we should focus on a core goal of our project. If we were a ruby only project, it would be worth consideration, but we are not.

So I'm for staying on system ruby 2.0.0, keep the stack and dependencies simple as possible and if we have some doubts about a critical bug or security issue in this ruby version, we can ask security folks about it.