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…
katello-4.1.2.1-1.el7.noarch.rpm is now published, this version bumped the requirement for `tfm-rubygem(foreman-tasks-core) and it’s likely to fix the dependency issue.
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
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.
