Hi!
I wanted to ask about the integration of Rocky Linux in Foreman and Katello.
As I’m quite new to this project and tried to wrap my head around all of the available features, and I noticed the implementation path for AlmaLinux, so I kind of know what is to do.
I just wanted to write before I open several Issues and PRs…
The current status of the Rocky Linux project is that the first RC got released as well as the first fixes for that. So is it too early to request the integration here?
As it is a 1:1 build of RHEL it kind of already works out of the box, so I already added a machine to my 3.18.2.1 Katello instance!
Regarding the needed changes, am I correct with these tasks?
open Feature Issue for Foreman and Katello
send PR for Foreman with the logos
send PR for Katello for the candlepin and rhsm detection
As far as I can see Ansible and Salt already got hooked up, so I would also need to get in touch with Puppet and Chef right?
I think you summed up pretty well what needs to be done. Another community member has done the same already and a core PR to add the OS to the Red Hat family and an icon:
If you do add an icon, we need to know that license wise we’re allowed to ship the files. it greatly helps if you can provide a link to the license or some explicit approval.
Then if you also want the content management, then Katello also needs a similar PR:
The icons are licensed as CC-BY-SA 4.0 so this shouldn’t be a problem
I opened now the Issues and PRs in Redmine and Github, I hope I didn’t make any mistakes, tried to follow the parsing of the names but I’m not completely sure if “Rocky” or “Rocky Linux” has to be used, it looked like the one in Foreman has to be different than in Katello.
Rocky linux works as a client, and yes, uses the same bits as centos. I have no problems getting updates and errata and so on.
BUT---- inside of katello, the OS shows up as “Unknown 8.4”. That’s my question, that we’re waiting for actual recognition of the OS within foreman.katello…
So, everything should be done for Rocky Linux 8, actually it is in since Foreman 2.5.1 and Katello 4.2.0
And I’m using it already a while now, for me the detection works as it should for me
(if I remember correctly it also got backported to Katello 3.18.2.1)
Off course everything only as client, as underlying server os would be a whole other topic.
Hm interesting, so for me, first they are shown as Unknown for a second and then they change to Rocky 8.4.
I’m unfortunately not too deep into how the whole thing works, but if I know that correctly the Operatingsystems have to be present (or will be created on the bootstrapping)
I have a similar issue with AlmaLinux where Content Hosts added via the bootstrap script get added as Unknown 8.4 regardless of the Operating System definition that I have. I was going to try Rocky Linux to see if it was a problem there as well, but looks like that is the case.
I do see that the bootstrap.py script has options for specifying an Operating System, so I’m wondering if the bootstrap.py script is not detecting AlmaLinux (or Rocky Linux) correctly and thus the Unknown 8.4 Operating System entry.
I think what I’ll do is manually specify the Operating System (using the -O or --operatingsystem arguments) and see if I still get the Unknown 8.4 association in Foreman.
Nope, so much for that theory… I ran the script in verbose mode and I can see the steps it’s performing which left me even more confused…
It performs a GET against the Smart Proxy for the host being registered, and I see it return the operatingsystem_id of 11 and operatingsystem_name of “Unknown 8.4”.
The script then performs the disassociate of the old Host entry (again specifying os_id 11) followed by the deletion of that host.
Then it calls the Foreman API to create the new host entry, and I can clearly see it specify operatingsystem_id 7 and operatingsystem_name “AlmaLinux 8”
If I do a hammer os list for my Foreman instance, I can see AlmaLinux 8 shown with ID 7 (same capitalization) – so I know the OS entry is there and it has the same ID as the bootstrap script passed during the creation, yet when I query the host via the GUI and hammer it shows the OS as Unknown 8.4.
OK, so While Katello 4.2 is still in release-candidate mode, I decided to pull the trigger anyway to Foreman 3 and Katello 4.2. (It’s a test server at this point anyway…!). I normally wait until official releases, but what the heck.
After the upgrade of my Katello server, my Rocky client still showed up as “Unknown 8.4”, so (as I dd with Katello 4.1.xx), I unregistered the client and registered it again. Note, it is entirely posssible that it would have been OK if I had waited for the client to check in; this is unknown and I was too impatiient to wait, ha…
Voila! After re-registtering with the Katello server ,the OS is now being properly recognized. WOOOOOO
Honestly, it is really good to wait a bit for prod systems, got hit really hard by 4.1.2 because of this pulp bug
It would be interesting if it would have worked with your 4.1.x install as well, but I suppose you don’t have a snapshot/backup right? ^^
No backups yet as it’s just a test system. My PRODUCTION system is still sitting on another host running 3.18.x.
I will probably wipe that clean and move to 4.2 once the release is finished and official.
And I’ve given up on the thought of trying to “upgrade” from 3.x to 4.x. There’s just way too many problems doing that. But I can repopulate everything and have all my hosts registered again in probably a day, and I know I’d spend WAY more time than that sorting out upgrade issues
I have to say I tried to upgrade, but I crashed on the switch from CentOS 7 with 3.18.x to CentOS/Rocky Linux 8 with 4.1.2, not really easy upgrade path when nearly everything changes at once
Backup and Restore looked to be the best option but that didn’t work for me, so I just did what you mentioned.
Setup from scratch and move everything over, was definitely a lot faster
Faster, and probably a whole LOT cleaner. I can’t imagine all of the breadcrumbs potentially left behind from upgrading from Katello 3.x to 4.x. With all the pulp cchanges and so on, I could see all sorts of incorrect database entries left behind and so on.
I of course give a huge kudos to the developers for trying, but well, I’m treating the katello 3–>4 upgrade like say, I would treat a windows box when moving from Windows 7 to Windows 10. There’s a LOT under the hood, and to be honest, it’s a whole lot cleaner to just start fresh.
Not for everyone of course; I have an infrastructure that’s well, “small enough” to do it. I can’t imagine having 5,000 clients and tryying to upgrade but many folk will have to.
(I just didn’t want to stitch that to another similar topic)
