Add rpm repo profile

[ehelms]

This is to provide the code to match the structure -- #1937

[ekohl]

Should we also link to https://github.com/theforeman/forklift/blob/master/vagrant/config/versions.yaml to figure out that mapping?

[ehelms]

Do you think we should try to display this mapping on https://theforeman.github.io/foreman-plugin-overview/ ?

[ekohl]

That's an interesting thought I hadn't considered. The URL might need to be changed to match the title (Foreman landscape) to reflect the broader scope.

[evgeni]

I was recently talking to @archanaserver and she also expressed confusion that this important information is so well hidden in a config file in some almost random repo.

So yeah, big 👍 on exposing that data somewhere in a nice way, but obviously shouldn't block this PR.

[ehelms]

If we look at the structure (from #1937):

├── candlepin
│   ├── 4.1
│   └── 4.2
├── foreman
│   ├── 3.9
│   │   ├── client
│   │   ├── foreman
│   │   ├── katello
│   │   └── plugins
│   └── nightly
│       ├── client
│       ├── foreman
│       ├── katello
│       └── plugins
└── pulpcore
    ├── 3.22
    ├── 3.28
    └── nightly

Given we won't have per katello-version repositories, I wonder if having a Katello repository makes sense. Let's look at what is in the Katello repo:

• katello RPMs
• Pulp API gems
• Plugins that require Katello
• a few rubygem and nodejs dependencies

I believe the three primary reasons we keep Katello separate today:

• Katello has a larger number of RPMs for itself and it's plugins
• Easier to have dedicated pipelines with a dedicated repository
• Katello RPMs are signed, plugins are not

I think the first point is not such a problem anymore, and could be reduced further through meta RPM elimination (perhaps through single scenario per installer RPM change).

We could start signing plugins as we've discussed.

The pipelines part we've discussed and never arrived at a good answer for.

So perhaps doing it through release RPMs is the easiest. And we can simplify a bit at least by aligning GPG signing key with this structure.

[ekohl]

I wouldn't mind dropping the specific katello repository. It does mean some additional preparation like updating procedures in theforeman-rel-eng and some RPMs, but it would resolve a long standing issue.

[ehelms]

I am feeling good about this and think it's ready for merge an getting applied to the host so that I can proceed with additional testing and updates.

[ehelms]

Based on conversation here -- #1937 (comment) I would like to:

• Merge this change to update rpm-repo1 to have the vhosts and structure for handling new releases
• Follow up PR to add vhost to handle yum.theforeman.org

[ekohl]

One small nit, but I think we can start rolling out the machine to experiment with. Then from there we can write up the exact migration plan.

[ekohl]

I should have added a comment, but I started this file with custom definitions first. Then around like 12 I started to map things. With the introduction of stable_release I think that already broke (and I should have noticed it there).

My question: how should we manage this? Do we want to keep things that we regularly change (i.e., real data) at the top while keeping more "internals" near the bottom or keep them close to each other since they're closely connected

[ehelms]

Split it into two files? That would be easier for me to understand. And I imagine be more obvious to newcomers.

[evgeni]

Two files sounds good to me!

[ehelms]

I am going to treat this as a follow up and merge this.

[ehelms]

Implemented this idea here