Excellent, thank you. You have convinced me, I am going to exclude version from product and use CV/Activation keys to get hosts using the right repos.
In poking around at something else I discovered that pulp repo-names are 128 characters... As such I am going to shorten some of my repo names a bit. ORG-repo-version-CV-aslkdfj;lkjasdf;lkj whatever katello does to name them can get pretty long pretty quick. -Alan On Thursday, November 10, 2016 at 2:15:35 PM UTC-7, Jason B. Nance wrote: > > 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: > > 1) I knew I was going to need/use CVs > 2) 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: > > 1) Share the same version of a CV across multiple different distros (for > example, EPEL 7 is used by both CentOS 7 and OEL 7) > 2) 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" <[email protected] <javascript:>> > *To: *"Foreman users" <[email protected] <javascript:>> > *Cc: *[email protected] <javascript:> > *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" <[email protected]> >> *To: *"Foreman users" <[email protected]> >> *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/ >> Repo: CentOS 6 x86_64 Updates - centos-6-x86_64-updates = >> http://mirror.centos.org/centos/6/updates/x86_64/ >> - or more generally - >> Repo: CentOS $major $arch $repo - lower(centos-$major-$arch-$repo) = >> lower(http://mirror.centos.org/centos/$major/$repo/$arch/) >> >> Product CentOS 7 (centos-7) >> Repo: CentOS $major $arch $repo - lower(centos-$major-$arch-$repo) = >> lower(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/ >> >> 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 >> 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 >> >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/foreman-users. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/foreman-users. For more options, visit https://groups.google.com/d/optout.
