4. Attaching and Removing Subscriptions

Assigning a subscription to a system gives the system the ability to install and update any Red Hat product in that subscription. A subscription is a list of all of the products, in all variations, that were purchased at one time, and it defines both the products and the number of times that subscription can be used. When one of those licenses is associated with a system, that subscription is attached to the system.

4.1. About Subscriptions

When a product is purchased from Red Hat, the resulting subscription contains all the details around that purchase, not just the product name:
  • All included products
  • Support levels for the products
  • The length of time that the subscription is valid
  • A contract number for the sale
  • The number of times that the subscription can be used
  • The content repositories for the products
Subscription Details

Figure 3. Subscription Details

All of that information is used to maintain the subscriptions across the infrastructure.

4.1.1. Pools and Available Subscriptions

When a product is purchased, its subscription defines a quantity, the number of times that the subscription can be used. That set of subscriptions is the pool. A product has a general ID that is universal. A pool has a specific ID that is only true for that specific subscription. A pool ID essentially relates a product to the subscription through which it was purchased.
[root@server1 ~]# subscription-manager list --available

    Available Subscriptions
ProductName:            RHEL for Physical Servers
ProductId:              MKT-rhel-server
PoolId: ff8080812bc382e3012bc3845ca000cb
Quantity:               10
Expires:                2013-09-20

4.1.2. About Relationships Between Subscriptions and Systems Interactions with Subscriptions, Products, and Systems
Products on a system have relationships, dependencies, and conflicts between each other. Likewise, subscriptions have relationships that parallel the relationships of the software it represents. Some subscriptions allow virtual guests, some require other subscriptions, some conflict with other subscriptions.
Subscription define the relationships between installed products and each other and the systems on which those products are installed. Likewise, subscriptions can also define relationships between systems and how they interact within an environment. This is particularly apparent with virtual environments, where subscriptions can define different relationships for physical hosts and virtual guests, but there are other ways that systems can interact, such as data centers and cloud infrastructures. Subscriptions are a part of those meta relationships.
Using subscriptions to define these relationships introduces a lot of flexibility in how products and systems interact:
  • Associate a single quantity of a product with a single system (which is the most common relationship).
  • Restrict one product so that it cannot be installed on the same system as a specific, different product.
  • Keep a system on a consistent service level. Each subscription includes a definition for what service level (e.g., standard or premium) the product has. Subscription clients first try to assign subscriptions of the same service level (and this can be enforced) so that the system has consistent support levels.
  • Allow virtual guests to inherit some subscriptions from their host.
  • Allow some hosts to have unlimited guests for a data center deployment.
  • Allow a single “subscription” to be broken across multiple systems. This works in something like Red Hat Cloud Infrastructure, where a single purchase actually covers four products — Red Hat Enterprise Linux, Red Hat OpenStack, Red Hat Virtualization, and Satellite 6 — and those products each have their own subscription which can be used on different systems to create the stack.
  • Stack or combine subscriptions of the same type to cover a system. Counting Subscriptions
Part of the subscription service inventory is keeping track of subscriptions – not just what subscriptions are purchased but how many of those subscriptions are available.
When a subscription is first purchased, it defines the quantity of times that the subscription can be used. The subscription count is based on a certain element of the underlying system, most commonly its socket count (but it can be something else, such as the number of cores, depending on the specific subscription). The element of a system or software which is directly covered by a subscription is called an instance.
For example, for the subscription for Red Hat Enterprise Linux for 2 sockets, the product is Red Hat Enterprise Linux and the attribute is a physical socket pair. The socket pair is the instance.
A single subscription quantity is usually tied to a single socket pair (or other attribute). A system with eight sockets, then, requires more subscription quantities to cover its socket count than a four socket system. (This is called stacking.)
This simplistic arrangement, however, does not apply to all subscriptions.
Starting in October 2013, Red Hat began introducing other types of subscription relationships, such as:
  • Multiple products with a single subscription (Red Hat Cloud Infrastructure)
  • Inheritable subscriptions
  • Data center subscriptions, which allow unlimited virtual guests (and only the host requires a specific subscription)
Additionally, the 2013 subscription changes altered how virtual guests are handled in subscriptions. There used to be subscriptions for physical systems and then different subscriptions for virtual guests. In the current subscription model, the same subscription is used for both physical and virtual systems – but the quantity used is different, depending on whether it is a physical system or a virtual one.
As stated previously, a single subscription quantity is used per socket pair on a physical system. A virtual guest counts as a single socket, not a socket pair – so it is essentially half of a subscription quantity. When virtual guests are added to the inventory, the total number of available subscriptions is multiplied by two (the instance multiplier). This allows the subscription count to stay in whole numbers, even with virtual guests taking only a “half” quantity.
However, with some subscriptions counts multiplied by two; data center virtual guests not consuming any individual subscriptions; some subscriptions (Cloud Infrastructure) relating to multiple products installed on different systems; and older, pre-2013-style subscriptions all in the same environment — the actual counts listed in the subscription utilization pages or subscription management tools may not appear to reflect the quantities purchased in the contract. The fundamental counts are the same; most of the differences reflect changes to keep the count whole or new, more flexible subscription types.

4.1.3. Validity and Expiration

When a subscription is purchased, it is valid for a specified amount of time. This is its validity period.
As a subscription reaches the end of its validity period (or if it is canceled), the rhsmcertd process tracks it. The subscription process then creates a system notification, using a message as it nears expiration and a warning after it expires.
When a system uses multiple subscriptions to cover a single product, then the product is considered covered until the earliest expiration of one of its subscriptions.
Validity periods are crucial for system maintenance, compliance tracking, and purchasing.
Enabling autoattaching on a system allows it to upadte its subscriptions automatically, so the system is always in a valid state as long as any subscription is available. This is covered more in Section 5.2, “Managing Subscription Expiration and Notifications”.