along the way of improving host registration, we came across the issue that we need to clean up the repositories that we provide for setting up the subscription-manager in certain cases. A lesson learned is that what works well for us is just a subset of various use cases of how those repositories are used during and after host registration. Hence, we decided to move the discussion from Revert "Fixes #37501 - Clean up custom repositories from host registration" by stejskalleos · Pull Request #10212 · theforeman/foreman · GitHub to this forum. The goal is to create a set of use-cases and based on that a draft for what could be improved (or not). I tried to summarize these things in the following:
Use cases for providing custom repositories at the host registration:
Foreman-only scenario
a) No use of subscription-manager. Users (most likely) want to keep repositories after registration (lean-up optional).
Foreman/Katello scenario with subscription-manager
a) Content should only be provided via subscription-manager
a.1) Public repository provides subscription-manager packages (clean-up optional)
a.2) Repositories are provided via a content-view that is later also consumed by subscription-manager. This can lead to problems if the same repository is provided from host registration and subscription-manager (clean-up mandatory).
b) Content is partly provided by subscription-manager
b.1) Users can expect the repositories to be available even after host registration is complete (clean-up optional)
Package installation scenario
a) The host installs packages during the initialization phase that are provided from the repositories which were added during host registration (clean-up optional).
Feel free to add/edit the above list.
From what is outlined above, I immediately see one problem which is in 2.a - if a repository is provided by a repo from a content view that is later on consumed by the subscription-manager anyways. Other than that, it seems to me, that cleaning up the repositories is not necessary but more of an optional feature.
As a conclusion, a possible implementation might contain a checkbox as an option whether to delete the custom repositories or not. An open question is the time at when the repositories should be deleted. If the repositories are problematic for the subscription-manager registration, they need to be deleted before. If the repositories are needed for host packages setup, they should be deleted only afterwards.
So as a result from this RFC, I would like to get a) the need/use case for repository cleanup and b) the point in the execution where those repositories should be deleted for each use case - if at all.
Within Katello we have the concept of kickstart repositories. They’re available without authentication because the installer needs the packages and at that point you can’t provide authentication.
I’d lean to taking this concept and introducing a Registration Repository. During the registration procedure they’re automatically added before and cleaned up after.
The result is that the user never has to add repositories manually, but they’re implicitly part of the content it’s subscribed to. It should also take the content source into account and automatically retrieve it from the correct Pulp instance.
Since there is no way (that I can see) to determine which repository would be needed for registration, I’d still keep it as a manual marking.
I have a couple of comprehension questions to understand the proposal better:
Where does the kickstart/registration repository come from? Does the user set up certain repos as a “registration repository”?
How is a registration repository associated with the OS that needs to use it during deployment?
Can I create a repository (containing for example subscription-manager and some dependencies), and then add it to say my Ubuntu 24.04 hostgroup (?) as a registration repository, and also add it to a CV that will ultimately be consumed by my registered Ubunut 24.04 host? In other words can I use one repo as both a “registration repositroy” and a normal CV repo?
I can answer all of this “as if it’s designed the same way as kickstart repositories.” @ekohl correct me if you had any different thoughts:
It’s a repository synced and managed by Katello, just like any other. In the case of kickstart repositories it’s a Red Hat repo, but I think for registration repository it could be a custom repo. (Note that by “custom repo” here I just mean its longstanding definition “non-Red Hat”, and as a side note I hate introducing yet another definition for “custom repository” in this RFC but I’m not sure what else we should call it.) It could be stored as a registration_repository_id field on the host’s content facet, and could be inherited from hostgroups just like any other field.
A registration repository isn’t associated per se with an OS; rather, the registration repositories available for a specific operating system and host are queried via a database search similar to this one
Yes, a registration repository designed in this way can also be used as a normal content view repo.
I was thinking that it could possibly be a simple boolean on a repository so you can later decide to turn a regular repository into a registration repository (and vice versa), but I don’t know the Katello internals so @jeremylenz is in a much better position to answer that. At least on points 2 and 3 it’s exactly as I had in mind.
Just one option I want to mention for clean up as I always get the impression that it is not commonly known. There is the option disable_system_repos für subscription-manager which will make it ignore all other repositories. This is (or at least was) set by the host parameter only_subscription_manager_repos.
By default it is currently not set and I am not sure if we should change this default, but at least it is an option to consider (as consultant it would make my life easier having all in Katello, but unfortunately not all customers want to have all repositories mirrored and staged).
So given we introduce something like a ‘kickstart/registration’ repository for custom repos, what happens to the input fields on the Host Registration page? Should they turn into some kind of selection field where you can pick some of the repositories that were previously added as registration repositories?
Thinking some more about the implementation: At the moment, the host registration lives in Foreman. Having a registration repository adds a hard dependency on Katello functionality. How should this be handled?
Anything that depends on synced content should be in Katello. Katello already adds some fields to the global registration form (activation key, for example). I think this could be added in the same manner.
And as for the database field, kickstart_repository_id is on the content facet, so I think content facet would make sense for the new field.
In Foreman we already have MediumProvider. In vanilla Foreman there’s the Medium model but Katello also brings an additional provider based on the synced content. Perhaps you can reuse that? It probably makes it easier as well for users if they can just select some medium instead of manually entering a URL.
There may be limitations. For example, Foreman’s medium depends on knowing the OS for the version and arch if the URL depends on it.
Still, from a design perspective that makes the most sense to me and deserves investigation.
