To allow more flexible releases and updates to the Rails packaging stack we are maintaining the proposal has been to copy tfm-ror51 Copr repositories to yum.theforeman.org and version them based on the Foreman release. For example, to create a
http://yum.theforeman.org/releases/1.17/tfm-ror51 yum repository that holds Rails 5.1.4 and a
http://yum.theforeman.org/releases/1.18/tfm-ror51 that holds Rails 5.1.6.
The packages would continue to be built on Copr but getting the repository copies onto
yum.theforeman.org properly becomes the question I’d like feedback on.
- Create routine or push button Jenkins job
- Deploy a customized yum.conf to web.theforeman.org
- Run reposync to sync contents to proper location
- Delete yum.conf
Similar to Option 1 but we deploy a permanent
yum.theforeman.org that is managed by puppet with a routine reposync.
Both of these options will still require us to create version specific Copr repositories. That is to say, we will still need a
tfm-ror51-5.1.4 and a
tfm-ror51-5.1.6 to prevent accidentally updating the wrong repository.
The more I investigate and deal with these Rails updates, I also wonder if we’d been better served in the future creating a single RPM that contains the entire Rails stack.
My initial feeling is that we should keep it simple. That means a manual sync is fine.
There is also a third option: a shared repository with multiple rails versions in it. Foreman would then depend on
= 5.1.4 or
= 5.1.6. Not sure how well that would work in practice.
A side benefit of hosting it on yum.theforeman.org is that people like me who run their foreman server IPv6-only can retrieve all repositories.
I’ve made a first pass at this by putting the various Rails SCL repositories on yum.theforeman.org. This places the repositories organized by Rails version. The following questions have been raised thus far on how we structure this:
I’m not sure the extra level is needed. I’d propose:
That way we can bump it from 5.1.4 to 5.1.6 without users noticing. This may be needed in case we need an upstream bugfix or security fix. I’d like to avoid users needing to change their repos.
I don’t follow why users would need to change their repos. We control the repository file that gets laid down with Foreman via the repository RPM. So whether we have it as
5.1.4 we still control when and how users get Rails updates unless I am missing something.
I think I’d like to support the use case of
yum update and you get the latest foreman. If we need to change the URL, then it becomes
yum update foreman-release && yum update unless I’m missing something.
Ahh you are supposing a Rails upgrade during the z-stream, which while unlikely could happen. Fair enough.
Exactly. I should have been a bit clearer about that.