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/

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

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" To: "Foreman users" 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/

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 [ mailto:foreman-users+unsubscribe@googlegroups.com | foreman-users+unsubscribe@googlegroups.com ] .
To post to this group, send email to [ mailto:foreman-users@googlegroups.com | foreman-users@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 ] .

Well, we take a somewhat different approach.

We sync directly from RedHat and hence (re)naming those repos in Satellite
isn't really an option. We base our setup on 'products' and 'os' a
'product' being really an 'os' and other things (applications, db etc). But
a 'product' can also be part of our core operating system. We do this to
play better with the RBAC model.

So we will have

P_<product>
R_<product>Yum
R
<product>_Puppet

The RBAC model only allows you to permission at the product level so we can
hand that of to that team.

We construct our OS as a content view:

CV_<os>
RHEL 6Server
P_<product1> # Ok, in reality you add the repository but this is
for representation, this is owned by <product1>
P_<product2> # Owner is <product2>

But also:

CV_<product>
P_<product>

We will also allow the following

CCV_<os><product> # This can be permissioned to <product> team to manage
CV
<os> # But they can't modify <os>
CV_<product> # But they can modify <product>

This is so that (for instance) we can control what goes into the OS and use
the RBAC controls to prevent the owner of <product> from being able to
modify that but allow them to control their own content views and publish /
promote as they see fit.

The we tie these to hostgroups structured:

HG_<os>/<region>/<lifecycle> # Assign CV_<os> here

or HG_<os>/<region>/<lifecycle>/<product> # Assign CCV_<os>_<product> here

We then use the same methodology for activation keys etc. So an activation
key is:

AK_<os><lifecycle> # Assigns all the products / os which
is in content view CV
<os> and is assigned to HG_<os>/<region>/<lifecycle>
AK_<os><product><lifecycle>

We build these programmatically.

··· On Wednesday, November 9, 2016 at 6:21:12 PM UTC-5, Alan Evans wrote: > > 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 >

Here's a run down of how i've tried approaching this, then I'll explain why
i've heard complaints from some users

Product: CentOS
Repos:

  • el6-64-os
  • el6-64-updates
  • el6-64-extras
  • el7-64-os
  • el7-64-updates
  • el7-64-extras

Product: EPEL
Repos:

  • el6-64
  • el7-64

Product: Internal
Repos:

  • el6-noarch-product1
  • el6-noarch-product2
  • el7-noarch-product1
  • el7-noarch-product2

So on a rhel 6 box via yum the repos end up being named like this:

ORG-CentOS-el6-64-os
ORG-CentOS-el6-64-updates
ORG-EPEL-el6-64
ORG-Internal-el6-noarch-product1

What ends up being the problem is the katello UI. In several places you
are only given a list of repositories to select from, so based on the above
you get a list like this:

Repos:

  • el6-64-os
  • el6-64-updates
  • el6-64-extras
  • el7-64-os
  • el7-64-updates
  • el7-64-extras
  • el6-64
  • el7-64
  • el6-noarch-product1
  • el6-noarch-product2
  • el7-noarch-product1
  • el7-noarch-product2

So I have users that want to try different routes but that means some
interesting results, like these names in yum:

ORG-CentOS-centos-6-64-os
ORG-CentOS-centos-6-64-updates
ORG-EPEL-epel-6-64
ORG-Internal-el6-noarch-product1

which is just duplication. Or

ORG-Linux-centos-6-64-os
ORG-Linux-centos-6-64-updates
ORG-Linux-epel-6-64
ORG-Internal-el6-noarch-product1

Which loads even more things into a single product, which i'm not a fan of
but maybe it doesn't matter.

Another concern that was raised was managing the repo selection in
activation keys. By grouping EL6&7 in the same Product and relying on
enabling/disabling in the activation keys it can be slightly annoying
managing a bunch of keys. Where as if we move to a Product like CentOS6,
then there is no enabling/disabling of repos to deal with. but we wrote a
simple bas function around that… but its definitely not ideal.

So Far i'm leaning towards not changing from the first schema I mentioned,
but the UI is definitely annoying with it.

-greg

··· On Wed, Nov 9, 2016 at 7:45 PM 'Jason B. Nance' via Foreman users < foreman-users@googlegroups.com> 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” alanwevans@gmail.com
*To: *“Foreman users” foreman-users@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/
Repo: CentOS 6 x86_64 Updates - centos-6-x86_64-updates =
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/)

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 foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
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 foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

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" <alanw...@gmail.com > > *To: *"Foreman users" <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/ > 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 foreman-user...@googlegroups.com . > To post to this group, send email to forema...@googlegroups.com > . > Visit this group at https://groups.google.com/group/foreman-users. > For more options, visit https://groups.google.com/d/optout. >

Greg,

Thank you for your thoughts. This is the kind of discussion I was hoping
for.

I considered using (and may still) a single "CentOS" repo and use
activation keys to get boxes assigned to the right repos. As I mentioned
to Jason I am still not clear on content-views but that is another topic.

>
> Here's a run down of how i've tried approaching this, then I'll explain
> why i've heard complaints from some users
>
>
> Product: CentOS
> Repos:
> - el6-64-os
> - el6-64-updates
> - el6-64-extras
> - el7-64-os
> - el7-64-updates
> - el7-64-extras
>

Seeing it actually done this way I am liking it a lot better.

> Product: EPEL
> Repos:
> - el6-64
> - el7-64
>
> Product: Internal
> Repos:
> - el6-noarch-product1
> - el6-noarch-product2
> - el7-noarch-product1
> - el7-noarch-product2
>
> So on a rhel 6 box via yum the repos end up being named like this:
>
> ORG-CentOS-el6-64-os
> ORG-CentOS-el6-64-updates
> ORG-EPEL-el6-64
> ORG-Internal-el6-noarch-product1
>
> What ends up being the problem is the katello UI. In several places you
> are only given a list of repositories to select from, so based on the above
> you get a list like this:
>
> Repos:
> - el6-64-os
> - el6-64-updates
> - el6-64-extras
> - el7-64-os
> - el7-64-updates
> - el7-64-extras
> - el6-64
> - el7-64
> - el6-noarch-product1
> - el6-noarch-product2
> - el7-noarch-product1
> - el7-noarch-product2
>
> So I have users that want to try different routes but that means some
> interesting results, like these names in yum:
>
> ORG-CentOS-centos-6-64-os
> ORG-CentOS-centos-6-64-updates
> ORG-EPEL-epel-6-64
> ORG-Internal-el6-noarch-product1
>
> which is just duplication. Or
>

Yeah I am not happy with having duplication all over like this either. The
OCD part of me ticks when I do it or think of doing it. But yeah you are
right, if you have only the repo name to look at you are missing some
context.

>
> ORG-Linux-centos-6-64-os
> ORG-Linux-centos-6-64-updates
> ORG-Linux-epel-6-64
> ORG-Internal-el6-noarch-product1
>
> Which loads even more things into a single product, which i'm not a fan of
> but maybe it doesn't matter.
>

Yeah I would agree here. This would be overloading the "Linux" product and
I think make things more confusing and complicated in the long run.

>
> Another concern that was raised was managing the repo selection in
> activation keys. By grouping EL6&7 in the same Product and relying on
> enabling/disabling in the activation keys it can be slightly annoying
> managing a bunch of keys. Where as if we move to a Product like CentOS6,
> then there is no enabling/disabling of repos to deal with. but we wrote a
> simple bas function around that… but its definitely not ideal.
>
> So Far i'm leaning towards not changing from the first schema I mentioned,
> but the UI is definitely annoying with it.
>
>
You could file a feature request to include the product name or label when
displaying repos. Maybe: "$repo_name ($product_name)" or "$product_name -
$repo_name", the second of which has the interesting side effect of
grouping things by product if sorted by name. And where labels are
concerned display them like they are used in pulp. Pulp doesn't even have
a conept of product, it just manages repos so pulp repo names just become
"$product_label" + "_" + "$repo_label".

··· On Wednesday, November 9, 2016 at 9:50:42 PM UTC-7, Greg Swift wrote:

-greg

On Wed, Nov 9, 2016 at 7:45 PM ‘Jason B. Nance’ via Foreman users < > forema...@googlegroups.com <javascript:>> 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” <alanw...@gmail.com <javascript:>>
*To: *“Foreman users” <forema...@googlegroups.com <javascript:>>
*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/

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 foreman-user...@googlegroups.com <javascript:>.
To post to this group, send email to forema...@googlegroups.com
<javascript:>.
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 foreman-user...@googlegroups.com <javascript:>.
To post to this group, send email to forema...@googlegroups.com
<javascript:>.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

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. :slight_smile:

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 ] .

This morning I went to go create all of this in our new Katello 3.2
instance and the Composite content views won't build because:

An error occurred updating the Content View: Repository conflict: 'el6-64'
is in Product1 Core 1.0, Weekly Core 1.0.,Repository conflict: 'el7-64' is
in Product1 Core 1.0, Product2 Core 1.0, Weekly Core 1.0.

So basically we have to make the repository names unique everywhere, which
means (most likely) the duplication of names i detailed in my previous
message.

yay

-greg

··· On Wed, Nov 9, 2016 at 10:50 PM Greg Swift wrote:

Here’s a run down of how i’ve tried approaching this, then I’ll explain
why i’ve heard complaints from some users

Product: CentOS
Repos:

  • el6-64-os
  • el6-64-updates
  • el6-64-extras
  • el7-64-os
  • el7-64-updates
  • el7-64-extras

Product: EPEL
Repos:

  • el6-64
  • el7-64

Product: Internal
Repos:

  • el6-noarch-product1
  • el6-noarch-product2
  • el7-noarch-product1
  • el7-noarch-product2

So on a rhel 6 box via yum the repos end up being named like this:

ORG-CentOS-el6-64-os
ORG-CentOS-el6-64-updates
ORG-EPEL-el6-64
ORG-Internal-el6-noarch-product1

What ends up being the problem is the katello UI. In several places you
are only given a list of repositories to select from, so based on the above
you get a list like this:

Repos:

  • el6-64-os
  • el6-64-updates
  • el6-64-extras
  • el7-64-os
  • el7-64-updates
  • el7-64-extras
  • el6-64
  • el7-64
  • el6-noarch-product1
  • el6-noarch-product2
  • el7-noarch-product1
  • el7-noarch-product2

So I have users that want to try different routes but that means some
interesting results, like these names in yum:

ORG-CentOS-centos-6-64-os
ORG-CentOS-centos-6-64-updates
ORG-EPEL-epel-6-64
ORG-Internal-el6-noarch-product1

which is just duplication. Or

ORG-Linux-centos-6-64-os
ORG-Linux-centos-6-64-updates
ORG-Linux-epel-6-64
ORG-Internal-el6-noarch-product1

Which loads even more things into a single product, which i’m not a fan of
but maybe it doesn’t matter.

Another concern that was raised was managing the repo selection in
activation keys. By grouping EL6&7 in the same Product and relying on
enabling/disabling in the activation keys it can be slightly annoying
managing a bunch of keys. Where as if we move to a Product like CentOS6,
then there is no enabling/disabling of repos to deal with. but we wrote a
simple bas function around that… but its definitely not ideal.

So Far i’m leaning towards not changing from the first schema I mentioned,
but the UI is definitely annoying with it.

-greg

On Wed, Nov 9, 2016 at 7:45 PM ‘Jason B. Nance’ via Foreman users < > foreman-users@googlegroups.com> 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” alanwevans@gmail.com
*To: *“Foreman users” foreman-users@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/
Repo: CentOS 6 x86_64 Updates - centos-6-x86_64-updates =
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/)

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 foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
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 foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

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" <alanw...@gmail.com > > *To: *"Foreman users" <forema...@googlegroups.com > > *Cc: *ja...@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" >> *To: *"Foreman users" >> *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 foreman-user...@googlegroups.com. >> To post to this group, send email to forema...@googlegroups.com. >> Visit this group at https://groups.google.com/group/foreman-users. >> For more options, visit https://groups.google.com/d/optout. >> > >

So yeah that's annoying… This is the kind of thing I was hoping to avoid.

I wonder instead of overloading the "repo" name in pulp if it made sense to
make pulp aware of products and content-views. So instead of just joining
things together it really understood /product-foo/el6-64/content-view/1.0.

Not that you and I are going to solve that here… Just brainstorming.

-Alan

··· On Wednesday, November 16, 2016 at 9:14:47 AM UTC-7, Greg Swift wrote: > > This morning I went to go create all of this in our new Katello 3.2 > instance and the Composite content views won't build because: > > An error occurred updating the Content View: Repository conflict: 'el6-64' > is in Product1 Core 1.0, Weekly Core 1.0.,Repository conflict: 'el7-64' is > in Product1 Core 1.0, Product2 Core 1.0, Weekly Core 1.0. > > > So basically we have to make the repository names unique everywhere, which > means (most likely) the duplication of names i detailed in my previous > message. > > yay > > -greg > > On Wed, Nov 9, 2016 at 10:50 PM Greg Swift > wrote: > >> Here's a run down of how i've tried approaching this, then I'll explain >> why i've heard complaints from some users >> >> >> Product: CentOS >> Repos: >> - el6-64-os >> - el6-64-updates >> - el6-64-extras >> - el7-64-os >> - el7-64-updates >> - el7-64-extras >> >> Product: EPEL >> Repos: >> - el6-64 >> - el7-64 >> >> Product: Internal >> Repos: >> - el6-noarch-product1 >> - el6-noarch-product2 >> - el7-noarch-product1 >> - el7-noarch-product2 >> >> So on a rhel 6 box via yum the repos end up being named like this: >> >> ORG-CentOS-el6-64-os >> ORG-CentOS-el6-64-updates >> ORG-EPEL-el6-64 >> ORG-Internal-el6-noarch-product1 >> >> What ends up being the problem is the katello UI. In several places you >> are only given a list of repositories to select from, so based on the above >> you get a list like this: >> >> Repos: >> - el6-64-os >> - el6-64-updates >> - el6-64-extras >> - el7-64-os >> - el7-64-updates >> - el7-64-extras >> - el6-64 >> - el7-64 >> - el6-noarch-product1 >> - el6-noarch-product2 >> - el7-noarch-product1 >> - el7-noarch-product2 >> >> So I have users that want to try different routes but that means some >> interesting results, like these names in yum: >> >> ORG-CentOS-centos-6-64-os >> ORG-CentOS-centos-6-64-updates >> ORG-EPEL-epel-6-64 >> ORG-Internal-el6-noarch-product1 >> >> which is just duplication. Or >> >> ORG-Linux-centos-6-64-os >> ORG-Linux-centos-6-64-updates >> ORG-Linux-epel-6-64 >> ORG-Internal-el6-noarch-product1 >> >> Which loads even more things into a single product, which i'm not a fan >> of but maybe it doesn't matter. >> >> Another concern that was raised was managing the repo selection in >> activation keys. By grouping EL6&7 in the same Product and relying on >> enabling/disabling in the activation keys it can be slightly annoying >> managing a bunch of keys. Where as if we move to a Product like CentOS6, >> then there is no enabling/disabling of repos to deal with. but we wrote a >> simple bas function around that... but its definitely not ideal. >> >> So Far i'm leaning towards not changing from the first schema I >> mentioned, but the UI is definitely annoying with it. >> >> -greg >> >> On Wed, Nov 9, 2016 at 7:45 PM 'Jason B. Nance' via Foreman users < >> forema...@googlegroups.com > 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" <alanw...@gmail.com > >>> *To: *"Foreman users" <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/ >>> 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 foreman-user...@googlegroups.com . >>> To post to this group, send email to forema...@googlegroups.com >>> . >>> 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 foreman-user...@googlegroups.com . >>> To post to this group, send email to forema...@googlegroups.com >>> . >>> Visit this group at https://groups.google.com/group/foreman-users. >>> For more options, visit https://groups.google.com/d/optout. >>> >>