Here are a couple screen shots that show the layout of one of my Katello instances:
Products:
https://tresgeek.net/cloud/index.php/s/RgYDpYl09ePjqWm
Content Views:
https://tresgeek.net/cloud/index.php/s/MByLW0Ho99rIFOS
(this instance doesn't have OEL, but it's pretty much the same as CentOS with some minor differences)
I, too, struggled with how to organize my products. I landed on this for a couple reasons:
- I knew I was going to need/use CVs
- Grouping by vendor/upstream felt "right"
Why CVs, you ask? For me it is to maintain consistency and give a path for rollbacks. Product repos are raw and versionless. You get what you get when you get it. CVs are basically snapshots or moments in time (handled via symlinks and database info).
I classify systems as either non-prod or prod, so my process looks like this:
Product repos are updated nightly.
CV version is created and prompted to "non-prod" the day before non-prod patching.
Non-prod systems patched.
A few weeks later, that same CV version is prompted to "production" the day before production patching.
Production systems patched.
That gives me a few weeks of bake-in time for updates before they go to production. It also means that a server installed on Friday as has the same versions of the same packages that were installed on a server of the same environment on Monday.
If an issue is discovered after patching, I can roll everything back to the previous known good CV version.
I also make use of Composite Content Views, which are just a collection of specific versions of CVs. CCVs allow a couple things to happen:
- Share the same version of a CV across multiple different distros (for example, EPEL 7 is used by both CentOS 7 and OEL 7)
- Allows a "sub" CV version to get wonky without breaking the whole process
Some elaboration on #2… My Katello box isn't always the happiest of things. Sometimes CV version creation/promotion fails. If it's the day before patching and my Software Collections CV version create/promote is failing and I don't have time to fix it, I don't want to have to delay patching (especially for such a "minor" repo in my environment). So with a CCV I can just use the last known good CV version of SCL in my CCV.
There's a bit more to this as how CVs, lifecycle envs, host groups, and activate keys all relate, but I'll stop the fire hose here for now. 
TL;DR: CVs are about maintaining consistency and content flow through your environment (IMO).
Clear as mud?
j
···
From: "Alan Evans"
To: "Foreman users"
Cc: jason@tresgeek.net
Sent: Thursday, November 10, 2016 12:41:04 PM
Subject: Re: [foreman-users] Naming products and repos?
Jason,
I have considered going to a single “CentOS” product. I still haven’t wrapped my head around content views. It seems like a needless layer of abstraction but maybe I just don’t get it yet.
Thanks for your thoughts, this is exactly the discussion I was hoping to have.
-Alan
On Wednesday, November 9, 2016 at 6:45:37 PM UTC-7, Jason B. Nance wrote:
HI Alan,
Regarding products, I organize by the upstream/vendor not by versions. For example, I have CentOS, OEL, and EPEL products. My content views are where I split up stuff into versions and such.
Your examples look good to me.
j
From: “Alan Evans” < [ javascript-blocked: | alanw...@gmail.com ] >
To: “Foreman users” < [ javascript-blocked: | forema...@googlegroups.com ] >
Sent: Wednesday, November 9, 2016 5:19:54 PM
Subject: [foreman-users] Naming products and repos?
Is there any guide or are there any recommendations for naming/labeling products and repos?
Is CentOS, CentOS 6, CentOS 6 x86_64 a product?
What are people doing for CentOS/EPEL?
If left to it’s own devices katello just replaces spaces with underscores for product/repo labels.
What about other “products?”
Is Katello a product? Katello 3.2?
Puppet? Puppet PC1?
Puppet Enterprise? Puppet Enterprise 2016.4? or is the product “Puppet” with repos for the versions?
I am leaning toward:
Product: CentOS 6 (centos-6)
Repo: CentOS 6 x86_64 OS - centos-6-x86_64-os = [ http://mirror.centos.org/centos/6/os/x86_64/ | http://mirror.centos.org/centos/6/os/x86_64/ ]
Repo: CentOS 6 x86_64 Updates - centos-6-x86_64-updates = [ http://mirror.centos.org/centos/6/updates/x86_64/ | http://mirror.centos.org/centos/6/updates/x86_64/ ]
Product CentOS 7 (centos-7)
Repo: CentOS $major $arch $repo - lower(centos-$major-$arch-$repo) = lower( [ http://mirror.centos.org/centos/$major/$repo/$arch/ | http://mirror.centos.org/centos/$major/$repo/$arch/ ] )
Product EPEL 6 (epel-6)
Repo: EPEL $major $arch - lower(epel-$major-$arch) = [ http://dl.fedoraproject.org/pub/epel/$major/$arch/ | http://dl.fedoraproject.org/pub/epel/$major/$arch/ ]
Puppet Enterprise (puppet-enterprise)
Repo: Puppet Enterprise 3.7.2 EL7 x86_64 - puppet-enterprise-3.7.2-el-7-x86_64 = [ https://puppet-master:8140/packages/3.7.2/el-7-x86_64 | https://puppet-master:8140/packages/3.7.2/el-7-x86_64 ]
Repo: Puppet Enterprise 2016.4 EL7 x86_64 - puppet-enterprise-2016.4-el-7-x86_64 = [ https://puppet-master:8140/packages/2016.4/el-7-x86_64 | https://puppet-master:8140/packages/2016.4/el-7-x86_64 ]
Thoughts?
-Alan
–
You received this message because you are subscribed to the Google Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [ javascript-blocked: | foreman-user...@googlegroups.com ] .
To post to this group, send email to [ javascript-blocked: | forema...@googlegroups.com ] .
Visit this group at [ https://groups.google.com/group/foreman-users | https://groups.google.com/group/foreman-users ] .
For more options, visit [ https://groups.google.com/d/optout | https://groups.google.com/d/optout ] .
