Tfm-rubygem-katello-4.1.2-1.el7.noarch dependency

There seems to be a new version tfm-rubygem-foreman-tasks-core.noarch:
tfm-rubygem-foreman-tasks-core.noarch 0:0.3.6-1.fm2_5.el7

However, package tfm-rubygem-katello-4.1.2-1.el7.noarch has a requires

Requires: tfm-rubygem(foreman-tasks-core) <= 0.3.5

Due to that an update fails:

Error: Package: tfm-rubygem-katello-4.1.2-1.el7.noarch (@ORG_katello_4_1_el7_x86_64)
           Requires: tfm-rubygem(foreman-tasks-core) <= 0.3.5
           Removing: tfm-rubygem-foreman-tasks-core-0.3.5-1.fm2_5.el7.noarch (@foreman-plugins)
               tfm-rubygem(foreman-tasks-core) = 0.3.5
           Updated By: tfm-rubygem-foreman-tasks-core-0.3.6-1.fm2_5.el7.noarch (foreman-plugins)
               tfm-rubygem(foreman-tasks-core) = 0.3.6

Confirmed. I’m having this issue too.

I may be completely wrong (for not understanding all the finer details) but why don’t we have specific repo paths for Foreman 2.5.0, 2.5.1, 2.5.2 and Katello 4.1.0, 4.1.1, 4.1.2 and for 2.5.x and 4.1.x the same gpg key is used.
At least when moving from repo 2.5.0 to say 2.5.2 you know what’s the end goal.
At the moment depending on the time we do a yum update we end up picking up bits and bobs that may or may not work.
Also if I’m on 2.5.0 + 4.1.0 repos I still want to be be able to do a yum clean all ; yum update for Linux updates (security fixes, new kernel) without having to worry that some bits for 2.5.1+ and 4.1.0+ are being picked up.

+1 to this.
I have been testing Foreman couple of weeks now, installing it three times from scratch and have already smashed up several times with different bugs and/or incompatibilities related to different and changing package versions. I wonder how nerve-racking it will be to use this in production environment…

We’re working on getting a Katello into the repos to fix this dependency issue. I’ll update when it arrives (perhaps tomorrow)

katello-4.1-rpm-pipeline [Jenkins] Currently running the release pipeline for to fix this issue. Sorry for the delay!


katello- is now published, this version bumped the requirement for `tfm-rubygem(foreman-tasks-core) and it’s likely to fix the dependency issue.

Fabulous! Foreman/Katello server upgraded just fine. Thank you!
And by the way now that my Foreman/Katello server is on the same version as my 2x external smart proxies this Smart proxy with 2.5.2/4.1.2... Not all necessary pulp workers running - #9 by fred_demarcy has been solved.

Having said that my comment about handling the repos differently still holds true.
Foreman 2.5.0, 2.5.1, 2.5.2, 2.5.x should not be in the same 2.5 repo
Katello 4.1.0, 4.1.1, 4.1.2, 4.1.x should not be in the same 4.1 repo.

You set up Foreman/Katello using repos 2.5/4.1 = ok. you get 2.5.0 + 4.1.0
Then feeling peachy you set up an external smart proxy using 2.5/4.1 = ok. you get 2.5.0 + 4.1.0
3-4 weeks down the line you want to set up another external smart proxy (noble thought right here); However during these 3-4 weeks updates have trickled in 2.5 & 4.1 repos for 2.5.x and 4.1.x …
Smart proxy installation picks up newer versions than your main Foreman/Katello server
A world of pain and cursing…
We’re forced to upgrade the main Foreman/Katello server + the existing proxy which is not a given considering what’s in the repos may not be ready for consumption…

With Foreman 2.5.0, 2.5.1, 2.5.x repos and Katello 4.1.0, 4.1.1, 4.1.x repos then you can stay on 2.5.0 and 4.1.0 and install how many smart proxies you need over a period of time because no packages have been upgraded. The only upgrades could be some very minor fixes that don’t even warrant to re-run the foreman-installer.
And when ready we can switch the release to 2.5.x + 4.1.x knowing exactly what we getting into.


I’d like to emphasize that this big of a change is rare and should be considered an outlier. It was weighed and the issues we had with the old Pulp tasking system were too big too fix. A rebase of Pulpcore to 3.14 is indeed quite extreme for a patch version and that choice wasn’t taken lightly.

That said, this tasks issue was really an oversight. Normally the goal is to have everything compatible so that you can compose the repositories. That did fail this time.

If you have strict requirements around this, it may be an idea to start using content views for your smart proxies. You can also consider a commercial vendor (like Red Hat’s Satellite or ATIX’s Orcharino).

Thanks @ekohl for the explanation.
Commercial vendors are not an option so I’ve just explained the issues I had. Whether what I’m saying is feasible, wanted or not wanted is not up to me :slight_smile:
At least in the future this is another aspect of the upgrade/installation process I’ll take into account.
Initially I had my main Foreman/Katello and my first smart proxy registered with content views and I elected to move away from this setup… Maybe something I’ll reconsider.