How to structure Products/Content views/Composite Views and activations keys? Confusing

Support
1

Hey there guys,

We have been attempting to best understand how to structure our
configuration in Satellite so that it's easy to maintain moving forward.
We're building a relatively large infrastructure with multiple app
components and several hundred servers so we're hoping to get it right
first time if we can :slight_smile:

Here's how we're thinking of naming and structuring each component of our
deployment. for the sake of the example below, we'll say that our company
is named "My Company" and our product is named "My Product" at "My
Location".

Organization

··· ==========================================================================

Examples seen in RedHat demos:

  • Seatech Science

  • Polycorp

  • Default_Organization

  • Superware

  • Goldensoft

  • Zemplex

Our proposal: My Company

Additional queries:

  • Should this be split by department? Will this allow for better control
    of roles and permissions to our Satellite instance?

Location

==========================================================================

Examples seen in RedHat demos:

  • Default_Location

  • San Francisco

Our proposal: My Location

Product

==========================================================================

Examples seen in RedHat demos:

  • Red Hat Enterprise Linux Server (relates to repo)

  • Red Hat Tools 6 Beta (relates to repo)

  • Wordpress (custom)

Our proposal:

  • Red Hat Enterprise Linux Server

  • Red Hat Enterprise Virtualization

  • EPEL 6

  • My Product (which will include RPM and Puppet repositories)

Additional queries:

  • Should we consider splitting My Product into 2 products? One for RPMs
    and one for Puppet (i.e. “My Product RPMs” and “My Product Puppet”)

Lifecycle

==========================================================================

Examples seen in RedHat demos:

  • Development

  • QA

  • Production

Our proposal:

  • Library > Development

  • Library > UAT 1

  • Library > UAT 2

  • Library > Production

Notes: We have chosen to this design becomes our code does not get deployed
into a linear lifecycle pattern as per usual, so we needed to keep each
stream separate and indepnedent.

Content View (incl. Composite Views)

==========================================================================

Examples seen in RedHat demos (Content Views):

  • ACME Tooling

  • EL6 SOE

    • Puppet Classes

      • motd

      • ntp

      • concat

      • firewall

      • mysql

      • stdlib

      • wordpress

    (note: I was a bit surprised to see such low-level classes assigned

    directly when RedHat officially recommend the roles and profiles
    pattern)

  • EL6 SOE with Tooling

  • LAMP Press

  • Wordpress

Examples seen in RedHat demos (Composite Content Views):

  • Wordpress Stack

    • RHEL 6

    • Wordpress

Our proposal:

  • My Product Stack (Composite)

    • RHEL 6

      • Red Hat Enterprise Linux 6 Server RPMs x86_64 6Server

      • Red Hat Enterprise Linux 6 Server - RH Common RPMs x86_64 6Server

      • (other Red Hat base repos)

      • EPEL 6

    • Base SOE

      • RPM Repository

      • Puppet Repository

    • My Product

      • RPM Repository (application)

      • Puppet Repository (application)

Queries:

  • Our goal is to publish puppet modules as quickly as possible without
    having to publish all the thousands of RPMs in the various Red Hat
    repositories. However, when we tested publishing of the composite view as
    described above, we found that it took as long if not longer than
    publishing the RHEL 6 content view. This seemed to defeat the purpose for
    us as it means that each time we push out Puppet code, we have a very long
    time to wait to publish the composite view that comprises the code. Are we
    purhaps missing something here?

  • How are others structuring their content views? Do many use composite
    views? What exactly are the pros and cons of using composite views? (we’re
    presuming it relates to activation key assignment but aren’t too sure)

Host Groups

==========================================================================

Examples seen in RedHat:

  • Wordpress

Our proposal:

  • Web Frontend

  • API

  • Database

Subscriptions (one per manifest)

==========================================================================

We notice that our Red Hat subscriptions show in here as expected, however
in addition to those, we see a subscription automatically added per
additional product that we add.

Queries:

  • What is the purpose of subscriptions based on our own products here?
    What purpose do they serve? Each of them state “X out of Unlimited” are
    used, and therefore we’re not quite sure why they are created?

Activation Keys

==========================================================================

This component is probably the one that’s confused us the most.

Our Proposal:

  • Create a My Product Key activation key and then ???

Queries:

  • It seems that we need an activation key for every content view /
    lifecycle environment combination? Is that correct? This seems rather
    tough to manage, is there any other way to simplify this?

  • It then seems that Host Groups need to be assigned an activation key in
    the “Activation Keys” tab as well. What’s the point of doing this here
    exactly? Since we are applying the activation key to a lifecycle
    environment already, shouldn’t Satellite inherit this license when being
    assigned to a host group that is assigned to this environment?

Overall, if someone could kindly explain how this component of the system
works, we’d appreciate it. The docs don’t seem to be getting the message
across and it has us rather stumped.

Thank you so much for your time and help in advance!

2

Sorry for ware and peace.

but anyone? Any one share how they are doing it?
best practice?

3

I'll answer some of the sections below that I'm familiar with subscriptions and activation keys.

>
>
> Hey there guys,
>
>
> We have been attempting to best understand how to structure our
> configuration in Satellite so that it's easy to maintain moving forward.
> We're building a relatively large infrastructure with multiple app
> components and several hundred servers so we're hoping to get it right
> first time if we can :slight_smile:
>
>
>
> Here's how we're thinking of naming and structuring each component of our
> deployment. for the sake of the example below, we'll say that our company
> is named "My Company" and our product is named "My Product" at "My
> Location".
>
>
>
> Organization
>
> ==========================================================================
>
> Examples seen in RedHat demos:
>
> - Seatech Science
>
> - Polycorp
>
> - Default_Organization
>
> - Superware
>
> - Goldensoft
>
> - Zemplex
>
>
>
> Our proposal: My Company
>
>
>
> Additional queries:
>
> - Should this be split by department? Will this allow for better control
> of roles and permissions to our Satellite instance?
>
>
>
> Location
>
> ==========================================================================
>
> Examples seen in RedHat demos:
>
> - Default_Location
>
> - San Francisco
>
>
>
> Our proposal: My Location
>
>
>
> Product
>
> ==========================================================================
>
> Examples seen in RedHat demos:
>
> - Red Hat Enterprise Linux Server (relates to repo)
>
> - Red Hat Tools 6 Beta (relates to repo)
>
> - Wordpress (custom)
>
>
>
> Our proposal:
>
> - Red Hat Enterprise Linux Server
>
> - Red Hat Enterprise Virtualization
>
> - EPEL 6
>
> - My Product (which will include RPM and Puppet repositories)
>
>
>
> Additional queries:
>
> - Should we consider splitting My Product into 2 products? One for RPMs
> and one for Puppet (i.e. "My Product RPMs" and "My Product Puppet")
>
>
>
> Lifecycle
>
> ==========================================================================
>
> Examples seen in RedHat demos:
>
> - Development
>
> - QA
>
> - Production
>
>
>
> Our proposal:
>
> - Library > Development
>
> - Library > UAT 1
>
> - Library > UAT 2
>
> - Library > Production
>
>
>
> Notes: We have chosen to this design becomes our code does not get deployed
> into a linear lifecycle pattern as per usual, so we needed to keep each
> stream separate and indepnedent.
>
>
>
> Content View (incl. Composite Views)
>
> ==========================================================================
>
> Examples seen in RedHat demos (Content Views):
>
> - ACME Tooling
>
> - EL6 SOE
>
> + Puppet Classes
>
> * motd
>
> * ntp
>
> * concat
>
> * firewall
>
> * mysql
>
> * stdlib
>
> * wordpress
>
> (note: I was a bit surprised to see such low-level classes assigned
>
> directly when RedHat officially recommend the roles and profiles
> pattern)
>
> - EL6 SOE with Tooling
>
> - LAMP Press
>
> - Wordpress
>
>
>
> Examples seen in RedHat demos (Composite Content Views):
>
> - Wordpress Stack
>
> + RHEL 6
>
> + Wordpress
>
>
>
> Our proposal:
>
> - My Product Stack (Composite)
>
> + RHEL 6
>
> * Red Hat Enterprise Linux 6 Server RPMs x86_64 6Server
>
> * Red Hat Enterprise Linux 6 Server - RH Common RPMs x86_64 6Server
>
> * (other Red Hat base repos)
>
> * EPEL 6
>
> * Base SOE
>
> - RPM Repository
>
> - Puppet Repository
>
> + My Product
>
> * RPM Repository (application)
>
> * Puppet Repository (application)
>
>
>
> Queries:
>
> - Our goal is to publish puppet modules as quickly as possible without
> having to publish all the thousands of RPMs in the various Red Hat
> repositories. However, when we tested publishing of the composite view as
> described above, we found that it took as long if not longer than
> publishing the RHEL 6 content view. This seemed to defeat the purpose for
> us as it means that each time we push out Puppet code, we have a very long
> time to wait to publish the composite view that comprises the code. Are we
> purhaps missing something here?
>
> - How are others structuring their content views? Do many use composite
> views? What exactly are the pros and cons of using composite views? (we're
> presuming it relates to activation key assignment but aren't too sure)
>
>
>
> Host Groups
>
> ==========================================================================
>
> Examples seen in RedHat:
>
> - Wordpress
>
>
>
> Our proposal:
>
> - Web Frontend
>
> - API
>
> - Database
>
>
>
> Subscriptions (one per manifest)
>
> ==========================================================================
>
> We notice that our Red Hat subscriptions show in here as expected, however
> in addition to those, we see a subscription automatically added per
> additional product that we add.
>
>
>
> Queries:
>
> - What is the purpose of subscriptions based on our own products here?
> What purpose do they serve? Each of them state "X out of Unlimited" are
> used, and therefore we're not quite sure why they are created?

Content from Red Hat is available via https to the content hosts and a subscription allows the content host access. When making a custom product (such as EPEL) there will be a subscription created so that custom content can be treated with the same infrastructure mechanisms (namely subscription-manager / RHSM).

For the custom products you could bypass this by creating /etc/yum.repos.d repo files by hand. This would content would then be entirely outside of activation keys, etc.

>
>
>
> Activation Keys
>
> ==========================================================================
>
> This component is probably the one that's confused us the most.
>
>
>
> Our Proposal:
>
> * Create a My Product Key activation key and then ???
>
>
>
> Queries:
>
> * It seems that we need an activation key for every content view /
> lifecycle environment combination? Is that correct? This seems rather
> tough to manage, is there any other way to simplify this?

Multiple activation keys may be used during subscription-manager register as long as one of them specifies the <lifecycle environment>/<content view> that the content host will be getting content from. You could therefore have a key that specifies this and an additional key that provides the subscriptions to the content desired.
actkey1 = Production
actkey2 = EL6-SOE subscriptions

>
> * It then seems that Host Groups need to be assigned an activation key in
> the "Activation Keys" tab as well. What's the point of doing this here
> exactly? Since we are applying the activation key to a lifecycle
> environment already, shouldn't Satellite inherit this license when being
> assigned to a host group that is assigned to this environment?

The activation key provides subscriptions to, potentially, a subset of the content that is available in a CV. Simply knowing the LE/CV is just a piece of the info needed.

··· ----- Original Message -----

Overall, if someone could kindly explain how this component of the system
works, we’d appreciate it. The docs don’t seem to be getting the message
across and it has us rather stumped.

Thank you so much for your time and help in advance!

–
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 http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

4

Answers in-line to some items.

> Hey there guys,
>
>
> We have been attempting to best understand how to structure our
> configuration in Satellite so that it's easy to maintain moving forward.
> We're building a relatively large infrastructure with multiple app
> components and several hundred servers so we're hoping to get it right
> first time if we can :slight_smile:
>
>
>
> Here's how we're thinking of naming and structuring each component of our
> deployment. for the sake of the example below, we'll say that our company
> is named "My Company" and our product is named "My Product" at "My
> Location".
>
>
>
> Organization
>
> ==========================================================================
>
> Examples seen in RedHat demos:
>
> - Seatech Science
>
> - Polycorp
>
> - Default_Organization
>
> - Superware
>
> - Goldensoft
>
> - Zemplex
>
>
>
> Our proposal: My Company
>
>
>
> Additional queries:
>
> - Should this be split by department? Will this allow for better control
> of roles and permissions to our Satellite instance?
>
>
>
> Location
>
> ==========================================================================
>
> Examples seen in RedHat demos:
>
> - Default_Location
>
> - San Francisco
>
>
>
> Our proposal: My Location
>
>
>
> Product
>
> ==========================================================================
>
> Examples seen in RedHat demos:
>
> - Red Hat Enterprise Linux Server (relates to repo)
>
> - Red Hat Tools 6 Beta (relates to repo)
>
> - Wordpress (custom)
>
>
>
> Our proposal:
>
> - Red Hat Enterprise Linux Server
>
> - Red Hat Enterprise Virtualization
>
> - EPEL 6
>
> - My Product (which will include RPM and Puppet repositories)
>
>
>
> Additional queries:
>
> - Should we consider splitting My Product into 2 products? One for RPMs
> and one for Puppet (i.e. "My Product RPMs" and "My Product Puppet")
>

Personal organizational preference really – if the puppet modules are
related to the repositories in the product then keeping them in a single
product makes sense to me. If you are trying to create a single repository
for holding all puppet modules for your entire system, or you want to
organize by puppet module then a product to hold them makes sense.

>
>
> Lifecycle
>
> ==========================================================================
>
> Examples seen in RedHat demos:
>
> - Development
>
> - QA
>
> - Production
>
>
>
> Our proposal:
>
> - Library > Development
>
> - Library > UAT 1
>
> - Library > UAT 2
>
> - Library > Production
>
>
>
> Notes: We have chosen to this design becomes our code does not get
> deployed into a linear lifecycle pattern as per usual, so we needed to keep
> each stream separate and indepnedent.
>

Makes sense but note that you can promote a content view to any lifecycle
environment regardless of ordering. In other words, if you had Lib > Dev >
Test > Prod you could promote from Dev to Prod if you needed to.

>
>
> Content View (incl. Composite Views)
>
> ==========================================================================
>
> Examples seen in RedHat demos (Content Views):
>
> - ACME Tooling
>
> - EL6 SOE
>
> + Puppet Classes
>
> * motd
>
> * ntp
>
> * concat
>
> * firewall
>
> * mysql
>
> * stdlib
>
> * wordpress
>
> (note: I was a bit surprised to see such low-level classes assigned
>
> directly when RedHat officially recommend the roles and profiles
> pattern)
>
> - EL6 SOE with Tooling
>
> - LAMP Press
>
> - Wordpress
>
>
>
> Examples seen in RedHat demos (Composite Content Views):
>
> - Wordpress Stack
>
> + RHEL 6
>
> + Wordpress
>
>
>
> Our proposal:
>
> - My Product Stack (Composite)
>
> + RHEL 6
>
> * Red Hat Enterprise Linux 6 Server RPMs x86_64 6Server
>
> * Red Hat Enterprise Linux 6 Server - RH Common RPMs x86_64 6Server
>
> * (other Red Hat base repos)
>
> * EPEL 6
>
> * Base SOE
>
> - RPM Repository
>
> - Puppet Repository
>
> + My Product
>
> * RPM Repository (application)
>
> * Puppet Repository (application)
>
>
>
> Queries:
>
> - Our goal is to publish puppet modules as quickly as possible without
> having to publish all the thousands of RPMs in the various Red Hat
> repositories. However, when we tested publishing of the composite view as
> described above, we found that it took as long if not longer than
> publishing the RHEL 6 content view. This seemed to defeat the purpose for
> us as it means that each time we push out Puppet code, we have a very long
> time to wait to publish the composite view that comprises the code. Are we
> purhaps missing something here?
>

This sounds like it would be worth filing a bug on (
Foreman).

> - How are others structuring their content views? Do many use composite
> views? What exactly are the pros and cons of using composite views? (we're
> presuming it relates to activation key assignment but aren't too sure)
>

I believe composites get a lot of use as it allows breaking down parts of
the stack into individual, manageable content views that can be
independently published/released and combined into a larger entity. Or, in
some cases, allow one group to control the SOE and one group to control the
application and combine them into a single deployable stack. They also
solve the current restriction of only being able to register to a single
content view at a time.

>
>
> Host Groups
>
> ==========================================================================
>
> Examples seen in RedHat:
>
> - Wordpress
>
>
>
> Our proposal:
>
> - Web Frontend
>
> - API
>
> - Database
>
>
>
> Subscriptions (one per manifest)
>
> ==========================================================================
>
> We notice that our Red Hat subscriptions show in here as expected, however
> in addition to those, we see a subscription automatically added per
> additional product that we add.
>
>
>
> Queries:
>
> - What is the purpose of subscriptions based on our own products here?
> What purpose do they serve? Each of them state "X out of Unlimited" are
> used, and therefore we're not quite sure why they are created?
>

Subscriptions are how a client gets access to a particular product and are
not restricted to Red Hat content. Even though they are listed as unlimited
(although we have had some requests to allow customizing this for custom
products), by using subscriptions there is a single unified interface for
how you grant access to products and thus repositories from the UI or
client side (when using subscription-manager).

··· On Mon, Jun 29, 2015 at 2:32 AM, Matzuba wrote:

Activation Keys

==========================================================================

This component is probably the one that’s confused us the most.

Our Proposal:

  • Create a My Product Key activation key and then ???

Queries:

  • It seems that we need an activation key for every content view /
    lifecycle environment combination? Is that correct? This seems rather
    tough to manage, is there any other way to simplify this?

  • It then seems that Host Groups need to be assigned an activation key in
    the “Activation Keys” tab as well. What’s the point of doing this here
    exactly? Since we are applying the activation key to a lifecycle
    environment already, shouldn’t Satellite inherit this license when being
    assigned to a host group that is assigned to this environment?

Overall, if someone could kindly explain how this component of the system
works, we’d appreciate it. The docs don’t seem to be getting the message
across and it has us rather stumped.

Thank you so much for your time and help in advance!

–
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 http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

–
Eric D. Helms
Red Hat Engineering
Ph.D. Student - North Carolina State University

5

Thanks for the feedback guys! appreciated.

You've filled in some blanks for me.

I've decided to create a number of CV that cater for the repositories we
need to present to hosts and then add these to a composite view so i only
need 1 activation key for the Hosts to be able to see the content.

  1. RHEL repos
  2. Vendor repos+ puppet modules
  3. Internal repos+ puppet modules
    = 1 Composite V

However, i need to cater for different types of hosts and the repositories
that they can see/be subscribed to, ie i have standard RHEL6 hosts as well
as RHEL-H hypervsiors and VMs - these need access to the visualization
repositories whereas the standard physical host don't

How do i cater for this? You mentioned that i can apply one activation key
to sort the ENV and the conent for a host and then another activation key
for what repos the host subscribes too, how do i reference this in my PXE
template? it doesn't seem clear

Is this the best way to do this? is there a different approach? I wanted
to avoided using lots of activation keys but if that is the only way then
happy to try it out!

thanks for the info!