Description of problem:

I am trying to remember the actual reason why I wrote up this testcase, but I think I have figured it out.


Steps to Reproduce:

Preparation:

You will need to configure your installation of subscription-manager to point to a katello server, versus RHN Production
You will need a client system registered which has (or has emulated) multiple CPU sockets.
To simulate an N socket system, we will create an overriding system fact
# echo '{"cpu.cpu_socket(s)":"8"}' > /etc/rhsm/facts/sockets.facts
# subscription-manager facts --list | grep cpu.cpu_socket
cpu.cpu_socket(s): 8
You will also need access to a manifest file which appropriately unlocks "stackable" subscriptions.

1. Auto-subscribe a multi-socket system, assuring subscriptions are  adequate for all sockets - do not modify the Quantity of subscriptions
2. After registering, navigate to system in webUI and observe subscriptions for a system, noting the Quantity + associated spinner for each subscription
3. Hover over the spinner/quantity
  
Actual results:
Nothing

Expected results:

Something indicating the purpose of this spinner...

Now... the up/down arrows seem sort of self explanatory, and I was trying to remember why I wanted more detail. I think I remember now.

* Higher-end server, which have multiple CPUs (*not* cores) require a subscription for each CPU in order to maintain compliance
* A user may look at a high-end server and wonder why a single server is consuming so many subscriptions and subsequently try to reduce them.
* Alternately, a user might try to grant a single subscription to a high-end server and scratch his head wondering why it is not in compliance.

Thus... we should have something -- in the tooltip ("Note: quantities are per CPU") and/or in the helptip (Note: To maintain compliance, a system requires consumption of a subscription for each physical CPU in a system. Please refer to $business_rules_document for more information") which outlines this functionality.

Additional info: