Problem:
There are some repositories which don’t provide a “collection” of all versions of a software like Kubernetes packages (at least I have not found any). For those I have to add each individual repository to Katello each time there is a new kubernetes minor version like https://pkgs.k8s.io/core:/stable:/v1.26/rpm/ https://pkgs.k8s.io/core:/stable:/v1.27/rpm/
…
They changed that from the old google cloud location in which there are all versions into one. But this is now deprecated.
I wanted to ask if there is any quicker way of handling this as opposed to adding each repo individually all the time as it increases maintenance overhead. I tried it with a wildcard in the upstream URL but that didn’t work.
Expected outcome:
Reduced maintenance of versioned upstream repositories by providing somehow a wildcard for upstream repos or some other way.
Foreman and Proxy versions:
foreman-3.3.1-1.el7.noarch
Foreman and Proxy plugin versions:
foreman-proxy-3.3.1-1.el7.noarch
Distribution and version:
Centos7 (we will be moving to AlmaLinux 9)
There is not going to be a wildcard for sync URLs. In effect this would mean simply syncing every repository present under some upstream base URL into a single Katello repository. This would create endless potential for unintended consequences and problems.
What then are your options?
If you think the way some software vendor or project structures their repositories is inconvenient, you can open a ticket with them. For example you could ask whoever is responsible for https://pkgs.k8s.io/ to provide a latest symlink, that always points at the latest release repo in a fixed location, e.g.: https://pkgs.k8s.io/core:/stable:/latest/rpm/. Also, are you certain they don’t have something like this already? It seems a bit mad! This means anyone who wants to upgrade to a new version needs to first update their repo configuration on the consuming host (or in your case, the URL in their Katello instance).
Within Katello you could:
Instead of creating a new repo for each new upstream v1.2* release repo, you could create a single repo and change only the upstream URL regularly to point at the new latest release. This would still require some effort for each new upstream version repo, but less than creating a whole new repo each time. You could even seek to automate this process via Hammer or Ansible.
You could try using Katello’s repo discovery feature to create each new repository. This feature allows you to list all the RPM repo’s available beneath a particular URL (e.g. https://pkgs.k8s.io/core:/stable:/) and then select the ones you would like Katello to create a new repo for. I am not sure to what extent that would “Reduce your maintenance”.
There's a dedicated package repository for each Kubernetes minor release. For example, repository called core:/stable:/v1.28 only hosts packages for stable Kubernetes v1.28 releases. This means you can install v1.28.0 from this repository, but you can't install v1.27.0 or any other minor release other than v1.28. Upon upgrading to another minor version, you have to add a new repository and optionally remove the old one
I can see the reasoning behind the change, but the management overhead is quite a lot for us. This is the exact issue with PowerDNS repositories which we also have.
The suggestion to change the upstream repo to the new version could work but the issue is then that you won’t get any patch version anymore from the previous minor version since every 4 months, they release a minor version, but patches continue to be released for another 4 months.
What could work is to have 2 repos instead: the current minor release and the last one. Then every 4 months you switch again. But that feels a bit like a hack to me.
The repo discovery feature doesn’t work on pkgs.k8s.io as this is not even browseable manually so katello can’t discover it.
I’m unclear if I’m doing something fundamentally wrong with the katello repo management and I’m curious if other people have a similar issue as I have.
It sounds like your requirement is that for example, some of your hosts are already using the v1.27 repo, but other hosts are still using v1.26 and those hosts should continue to get minor updates from that repo. In that case I believe you need to have two separate repos in Katello. Or more generally:
You need at least one repo for each version of the k8s repo where you still have hosts that should continue to get updates for that minor version.
In that case it might be easiest to create a fixed repo in Katello for each upstream version repo, and then manage everything else via content views and lifecycle environements (which I believe is what you are currently doing?). This does require creating a new Katello repo each time you want to start using a new upstream repo, and then adding that repo to your content views, etc. If you experience this workflow as “too much maintenance”, then I think your best chance is to automate that workflow (or parts of it) using Hammer, Ansible, and/or API.
I don’t think there is a better (=less work) GUI workflow for managing this particular upstream release model along with your particular requirements for how you want to use that release model. My 2ct.
