Trying to figure out how to create release versions for centos. That is, syncing repos for 7 (latest), 7.4, 7.3, etc and using release versions in activation keys and/or subscription manager. I understand how to do this with redhat repos, but cannot figure it out for custom products.
It seems that creating a repository-set and having repositories contained in there is how it works, but I cannot figure out how to create new repository sets from scratch. I’ve tried searching the hammer documentation as well as pulp-admin to no avail.
Seems like should be able to create multiple versions of custom products.
It’s hard to know which way you would rather set it up - you could create a single Product, and then have multiple content views or composite content views.
Alternatively, you could have multiple Products, each with a single content view.
Thanks for the reply. Right, I’ve got that basic usage down pretty well no prob. I’ll try to explain better. When I add a Redhat Repo, I am able to pick multiple repos and define which version to use at the activation key. You can see this behavior when checking repository-sets with hammer:
This was done by enabling the RHEL 7 Server (RPMs) product. I am trying to replicate this behavior for a custom product. When trying to do this with CentOS 7, I can create separate products, CVs, and keys, sure. Or I can pack all repos into a single product and use the CV and keys to target the right version, but I can’t seem to find a way to create a single product, single CV, but a key targeting the release version (or use --releasever in subscription-manager).
I’m finding hard to describe what i’m trying to do in text, but that’s the gist, hah. At this point, i’m trying to figure out if there’s a way to manually create repo sets and attach repos to them. Obv it’s being done somehow when adding RH products, just not exposed easily for custom products.
Have you figured out how to manage multiple versions with CentOS? I don’t think it’s a wise idea to set 6 different products (as today) just to keep the point releases plus the plain 7 release with the latest packages that gets updated when the next point release is released.
I suppose you can just create new repo for the existing product. For that repo just specify the Upstream URL that has necessary package versions. Like http://mirror.centos.org/centos/7.6.1810/
I don’t know, in RHEL when we talk about Red Hat Enterprise Linux 7 Server (RPMs) it’s equivalent to CentOS “os” directory, so it would be: http://mirror.centos.org/centos/7.6.1810/os; this generates another problem: a product for each repository: extras, updates, etc. Correct me if I’m wrong please.
So at this moment I’m with the same issue, the Product thing is really confusing. I’ve look through the list history and the confusion is present in a lot of posts. There are ppl that just put a product named CentOS and put everything from 5 to 7, other considers a product a major release, and etc.
Another question is why pulp can’t just create a folder structure for CentOS just like the official mirrors, it would be simple, but we don’t have the control to create our own path structure within the web interface.
@ferrao
I never found a way to accomplish this. It stands to reason that there is a mechanism to accomplish it somewhere buried in the code, but the functionality is not exposed in any usable way that I’ve been able to discover. The functionality (currently) seems exclusive to Red Hat products, content, and repositories
Probably the next best thing would be to add all the version locked repositories into a single product and use activation keys to enable and disable the ones you want. That would get you relatively close to the same, but you would not be able to choose a release version in the key like i was attempting to do in my original post, sadly.
BTW, what I mentioned in the second half of my last response is exactly how I “faked” the functionality. Here is what I did:
Create Product (e.g. CentOS 7)
Add repositories for CentOS 7 (os/updates/extras) from mirror
Add repositories for version locked CentOS 7 (e.g. 7.5.1804) from vault
Sync repositories, create content view, publish to desired lifecycle environment.
Create activation key for CentOS 7, add subscription for product. In repository sets, disable 7.5 repos.
Create key for CentOS 7.5, add subscription for same product. In repository sets, disable 7 repos.
After this, you should have one product and one content view hosting repos for multiple versions. You will have one key for each version. Technically all the repos will be exposed to the clients, but will be disabled by default. If you really didn’t want the repos exposed at all, then you could still use a single product, but would need different content views and only add the repositories for each version, then use separate keys for each CV.
The real downside of this way is having such a large content view to publish, promote, and sync with smart proxies. Also slightly further complicating this particular example is adding CEFS functionality so that I have proper errata. Out of scope for my example but it’s just a bit more work. Well worth it for CentOS deployments though.
