Bug 800798

Summary: The system will over consume the pools after restarting rhsmcertd service .
Product: [Retired] Subscription Asset Manager Reporter: Hui Wang <huiwang>
Component: candlepinAssignee: Bryan Kearney <bkearney>
Status: CLOSED NOTABUG QA Contact: Entitlement Bugs <entitlement-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 1.0.0CC: cduryee, khong
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-07 16:35:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 703617    

Description Hui Wang 2012-03-07 09:56:03 UTC
Description of problem:
The guest will autosubscribe all the available pools instead of the pool matched exectly after restarting rhsmcertd service or waiting for 
"healFrequency" seconds.

Version-Release number of selected component (if applicable):
katello-headpin-all-0.1.141-1.el6.noarch
katello-common-0.1.301-2.el6.noarch
katello-configure-0.1.100-7.el6.noarch
katello-trusted-ssl-cert-1.0-1.noarch
katello-qpid-broker-key-pair-1.0-1.noarch
katello-certs-tools-1.0.2-2.el6.noarch
katello-selinux-0.1.8-1.el6.noarch
katello-cli-common-0.1.100-2.el6.noarch
katello-httpd-ssl-key-pair-1.0-1.noarch
katello-cli-headpin-0.1.15-2.el6.noarch
katello-glue-candlepin-0.1.301-2.el6.noarch
katello-headpin-0.1.141-1.el6.noarch
candlepin-0.5.23-1.el6.noarch
candlepin-tomcat6-0.5.23-1.el6.noarch
thumbslug-0.0.21-1.el6.noarch
virt-who-0.5-5.el5
subscription-manager-0.98.14-1.el5

How reproducible:

sometimes

Steps to Reproduce:
1.Install guest on host1 
2.Resgister host1, host2 and guest to SAM useing
username/password/org(admin/admin/ACME_Corporation)
3.Guest consumed the bonus pool on host1, then move/migrate to host2
4.Refresh the local data on guest, and then restart rhscmcertd service or waiting for "healFrequency" seconds.
5.Check the consumed pools on guest.
[root@72162 ~]# subscription-manager  list --consumed
+-------------------------------------------+
    Consumed Product Subscriptions
+-------------------------------------------+


ProductName:        	Red Hat Enterprise Linux Resilient Storage (for RHEL Server)
ContractNumber:     	2635105                  
AccountNumber:      	1508153                  
SerialNumber:       	3690836645444544505      
Active:             	True                     
QuantityUsed:       	1                        
Begins:             	11/21/2011               
Expires:            	11/21/2012               


ProductName:        	Red Hat Enterprise Linux Load Balancer (for RHEL Server)
ContractNumber:     	2635105                  
AccountNumber:      	1508153                  
SerialNumber:       	3690836645444544505      
Active:             	True                     
QuantityUsed:       	1                        
Begins:             	11/21/2011               
Expires:            	11/21/2012               


ProductName:        	Red Hat Enterprise Linux High Availability (for RHEL Server)
ContractNumber:     	2635105                  
AccountNumber:      	1508153                  
SerialNumber:       	3690836645444544505      
Active:             	True                     
QuantityUsed:       	1                        
Begins:             	11/21/2011               
Expires:            	11/21/2012               


ProductName:        	Red Hat Enterprise Linux Server
ContractNumber:     	2635105                  
AccountNumber:      	1508153                  
SerialNumber:       	3690836645444544505      
Active:             	True                     
QuantityUsed:       	1                        
Begins:             	11/21/2011               
Expires:            	11/21/2012      

Actual results:
The guest will auto subscribe all the available pools.

Expected results:
The guest will auto subscribe the pools that it needs.

Additional info:

Comment 1 Chris Duryee 2012-03-07 16:35:09 UTC
Hui,

I looked at this further this morning, it turns out that this is the correct behavior. All of the contract numbers and serial numbers are the same, which indicates that a single entitlement was pulled down that supplied multiple products, and was not a case of autoheal binding to too many entitlements.

Marking as CLOSED/NOTABUG, but I will see if there's a better way to display the data.