This is achieved by using RHN or RH Satellite and an activation key, though I don't know how well documented it is in RHOS.

Parameters are added to the OS for satellite_type (hosted or site), the satellite_host (if site) and the activation key.  The activation key should include the base OS and the RHOS subscription for any hosts you're deploying, which will enable access to the repos.

@dcleal: subscription manager will handle installing the repo definitions based on the SKU being used.  So for example, the RHEL OSP SKUs should cause you to automatically see RHEL LB, MRG-M 2.3, Ruby SCL and other repos in your /etc/yum.repos.d/redhat.repo file.

However, subscription manager does not (and in fact right now, can not) enable these repos.  They would come in as disabled.

So, Foreman needs to explicitly enable the right repos that are present on the system

Foreman also needs to make sure that the system it is provisioning registers via subscription-manager to get access to the right product.  Packstack currently does this today by allowing the user to specify RHN credentials when you run it.  On each system it is provisioning RHEL OSP into, it then uses those credentials to run subscription-manager to enable the right product and get access to the right channels

The kickstart snippet we ship uses rhnreg_ks only, no subscription-manager support, so I think any and all channels specified by the activation key used will be immediately available to yum.

We just hit the same problem with sub-man in Satellite 6, so we should add a generic sub-man snippet which can solve that problem.

We don't want to use credentials at all in this, activation keys are the way to avoid asking and storing user credentials for unattended provisioning.

(In reply to Dominic Cleal from comment #4)
> The kickstart snippet we ship uses rhnreg_ks only, no subscription-manager
> support, so I think any and all channels specified by the activation key
> used will be immediately available to yum.

We need subscription manager support...  I thought we are being advised to discontinue use of rhn-classic going forward.

@bkearney?

> We just hit the same problem with sub-man in Satellite 6, so we should add a
> generic sub-man snippet which can solve that problem.

ack

> We don't want to use credentials at all in this, activation keys are the way
> to avoid asking and storing user credentials for unattended provisioning.

Agreed with that part :)

*** Bug 1012186 has been marked as a duplicate of this bug. ***

I am confused - if Satellite is having the same problem, and there is talk of solving it in a generic way - is there something we can use here for RHOS, or do we need to roll our own solution for this for now?

(In reply to Jason Guiditta from comment #8)
> I am confused - if Satellite is having the same problem, and there is talk
> of solving it in a generic way - is there something we can use here for
> RHOS, or do we need to roll our own solution for this for now?

I think we'll probably do something generic for subscription-manager and repo support soon which we can use here, but for the meantime I think the existing RHN Classic/rhnreg_ks solution is working.

If we want to switch now to using sub-man we can put a snippet together pretty quickly and add it to the seed script.

In an attempt to clarify the problem we are trying to solve, I think a critical distinction is provisioning vs. non-provisioning.  I.e., when Foreman is running in Provisioning mode, we use Foreman's notion of Installation Media and Provisioning Templates (which includes registration scripts) to handle channel/repo subscriptions.  When using Foreman in the non-prov. case, it is up to the user that their already provisioned host has the right subscriptions before applying it to a given host group.

Foreman supports associating "Provisioning Templates" with individual Host Groups, so we can look to take advantage of that for different subscription sets among the Host Groups (this association step occurs when creating a host before it actually gets provisioned).

That said, I think we should *not* be doing anything within the puppet manifests associated with the Host Groups to set subscriptions; we would *not* alter an already provisioned system's subscriptions when a user uses the Foreman UI to change its Host Group.

I believe this is in-line with Dominic's previous comment (e.g., "the existing RHN Classic/rhnreg_ks solution" is using the redhat_register provisioning template/snippet which is only applicable when Foreman is in provisioning mode).

(In reply to Crag Wolfe from comment #10)
> Foreman supports associating "Provisioning Templates" with individual Host
> Groups, so we can look to take advantage of that for different subscription
> sets among the Host Groups (this association step occurs when creating a
> host before it actually gets provisioned).

Indeed, though we can even set activation keys on a per-host group basis via parameters (they're on the OS currently) if it actually has to vary between types of hosts.  My understanding is that it's the same subscription set though.

> That said, I think we should *not* be doing anything within the puppet
> manifests associated with the Host Groups to set subscriptions; we would
> *not* alter an already provisioned system's subscriptions when a user uses
> the Foreman UI to change its Host Group.

Agreed, for the non-provisioning case this should be documented if it isn't already (I recall it was for RHOS 3).

> I believe this is in-line with Dominic's previous comment (e.g., "the
> existing RHN Classic/rhnreg_ks solution" is using the redhat_register
> provisioning template/snippet which is only applicable when Foreman is in
> provisioning mode).

Yep.

Closing this off as I think we've covered the necessary points.

In provisioning mode, Foreman will use rhnreg_ks (RHN Classic, or RH Satellite 5) to set up appropriate channels using an activation key.

In non-provisioning mode, the user is responsible for registering hosts prior to running Puppet, as documented.

I've filed bug #1039910 for subscription-manager support during provisioning, to replace rhnreg_ks.