= Background =

Cloud providers will be issued one certificate to use to connect to Red Hat. That will contains all the entitlements they need, for example: RHEL 5, RHEL 6, RHUI, and certification scripts (abbreviated STS for some reason).

The thing is, that's kinda like two different styles of entitlements. The RHEL ones are definitely for the customer. The RHUI/STS ones aren't really. They are meant for the cloud provider's use in setting up the RHUI environment.

So that's one issue, we might want to clarify that. I *hope* that they wouldn't go throwing entitlements all willy-nilly into client certificates, but who knows.

The bigger issue is that these entitlements are defined to use variables for their repo URLs. There are two of them:

$releasever - will be 5Server or 6Server, depending on if the client is a RHEL 5 or 6 box.

$basearch - i386 or x86_64, again being taken from the client it's running on.

That's for all entitlements, including the RHUI ones. (I'm going somewhere with this, trust me).

RHUI isn't supported on RHEL 6 just yet. So we just flat out don't have the packages for it. So if the cloud provider attempts to use a client config RPM that has a RHUI entitlement/repo on a RHEL 6 box, it will fail.

Put a little less technically, we might be able to say that since RHUI isn't supported on RHEL 6, they cannot generate an entitlement certificate with RHEL 6 and RHUI entitlements on the same certificate.

Does that make sense? It's a lot of lead up for what will probably be a warning note in the docs, but I wanted to explain what it was so you can pretty it up rather than just saying "Tell them not to do that."