One big content view or multiple customized content views for EPEL, SCL, and others?

Support
1

I don't know if there is one right answer, but I'd like to know what others
are doing in similar situations.

In my case, I have RedHat 6 & RedHat 7 distros with Dev -> Test -> Prod
envs. I have products and sync'd repositories for Puppet, Katello, Katello
Client, EPEL, Software Collection Library, PostgresPlus Advanced Server,
and several others.

For the most part - there is seldom a conflict between repos, but today, I
tried to update katello and found that EPEL was creating a dependency
conflict and had to disable EPEL repo.

At one point, I thought it made more sense to have RedHat 7, RedHat 7 +
EPEL, RedHat 7 + EPEL + SCL, etc… but I'd end up with 5+ content views for
each EL major release. If my understanding of Activation Keys is correct,
I'd have 15+ activation keys for each major release.

This seems to make more sense - I could create two content views called
RedHat 7 and RedHat 6 and then I'd only need 6 different Activation keys
(right?) EL7dev, EL7test, EL7prod, etc… and then I can use
subscription-manager to enable or disable the repositories I want to use on
each content host right? This sounds like the simplest way of managing
things, but the Content Views will have a large number of packages in each
and I'd be relying on subscription-manager to enable or disable the correct
ones.

Is my understanding of Content Views, subscription-manager, Activation
Keys, and how content hosts all relate to these correct?

Is what I laid out how most handle multiple products but you don't enable
the repositories unless necessary?

2

Eric,

I ran into the same problem of design. My final solution was this:

  1. 1 massive CV (Includes RHEL 6, 7) called SOE
  2. create exclude filter by package
    2. add desired packages
    3. only applicable to certain repos
  3. Create activation keys
    1. RHEL 7
      1. CV: SOE
      2. Release version: 7server
      3. Product content: disable any RHEL 6 repos, and any other
        desired repos (using the overrides options)
    2. RHEL 6
      1. CV: SOE
      2. Release version: 6Server
      3. Product content: disable RHEL 7 repos, and any other desired
        repos (using the overrides options)

This method keeps the CV's to a minimum, but then use the activation keys
to disable the repos that shouldn't be there. This also assumes that your
patching cycle is the same for RHEL 6 and RHEL 7 since when you
publish/promote it snapshots both 6&7 at the same time. If that is not a
desired effect, separating the CV's into RHEL 6 and RHEL 7 isn't a bad way
to go either, it just becomes a pain.

··· On Wednesday, June 3, 2015 at 10:41:32 PM UTC-4, Eric du Toit wrote: > > I don't know if there is one right answer, but I'd like to know what > others are doing in similar situations. > > > In my case, I have RedHat 6 & RedHat 7 distros with Dev -> Test -> Prod > envs. I have products and sync'd repositories for Puppet, Katello, Katello > Client, EPEL, Software Collection Library, PostgresPlus Advanced Server, > and several others. > > For the most part - there is seldom a conflict between repos, but today, I > tried to update katello and found that EPEL was creating a dependency > conflict and had to disable EPEL repo. > > At one point, I thought it made more sense to have RedHat 7, RedHat 7 + > EPEL, RedHat 7 + EPEL + SCL, etc.. but I'd end up with 5+ content views for > each EL major release. If my understanding of Activation Keys is correct, > I'd have 15+ activation keys for each major release. > > This seems to make more sense - I could create two content views called > RedHat 7 and RedHat 6 and then I'd only need 6 different Activation keys > (right?) EL7dev, EL7test, EL7prod, etc.. and then I can use > subscription-manager to enable or disable the repositories I want to use on > each content host right? This sounds like the simplest way of managing > things, but the Content Views will have a large number of packages in each > and I'd be relying on subscription-manager to enable or disable the correct > ones. > > Is my understanding of Content Views, subscription-manager, Activation > Keys, and how content hosts all relate to these correct? > > Is what I laid out how most handle multiple products but you don't enable > the repositories unless necessary? > > > > > >
3

I think I've come to the same conclusion you did. Here is how I have ours
set right now:

  • 1 CV for each Major release (RHEL6, RHEL7, CentOS6, CentOS7) with all
    EPEL, Katello, Puppet, etc. repositories in the CV
  • 1 key for each Release&Env
  • in Kickstart, my subscription-manager snippet disables all non-standard
    repositories

With Dev,Test,Prod - this results in 12 activation keys, but they are
managed by Foreman so setting the correct environment for the host assigns
the correct activation key so it's not difficult to manage.

What I think is if a project or hostgroup needs a specific repository (PPAS
or EPEL), that repo can be enabled by a puppet module.

It sounds similar to what you are doing.

··· On Friday, June 5, 2015 at 2:17:40 AM UTC-5, Michele Newman wrote: > > > I ran into the same problem of design. >