Bug 994997

Summary: It takes 2 instance based subscriptions to make a virt-system compliant on firstboot
Product: Red Hat Enterprise Linux 5 Reporter: Shwetha Kallesh <skallesh>
Component: subscription-managerAssignee: John Sefler <jsefler>
Status: CLOSED ERRATA QA Contact: IDM QE LIST <seceng-idm-qe-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.10CC: bkearney, dgoodwin, jesusr, jsefler, redakkan
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
No description necessary
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-30 23:16:02 UTC Type: Bug
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: 840995    
Attachments:
Description Flags
2 quantities of instance based subscription
none
only 1 entitlement from an instance based subscription is required for compliance for a virt guest during firstboot none

Description Shwetha Kallesh 2013-08-08 11:35:13 UTC
Created attachment 784313 [details]
2 quantities of instance based subscription

Description of problem:
It takes 2 instance based subscriptions to make a virt-system compliant on firstboot but only 1 on cli

Version-Release number of selected component (if applicable):
[root@localhost ~]# subscription-manager version
server type: Red Hat Subscription Management
subscription management server: 0.8.19-1
subscription-manager: 1.8.16-1.el5
python-rhsm: 1.8.16-1.el5

How reproducible:


Steps to Reproduce:
1.Firstboot -r 
2.Register with auto-bind
3.after register is done,

[root@localhost ~]# subscription-manager list --consumed
+-------------------------------------------+
   Consumed Subscriptions
+-------------------------------------------+
Subscription Name: Awesome OS Instance Based (Standard Support)
Provides:          Awesome OS Instance Server Bits
SKU:               awesomeos-instancebased
Contract:          42
Account:           12331131231
Serial:            7981328188174773976
Pool ID:           8ac6a3a2405c7fed01405c80f7f50808
Active:            True
Quantity Used:     2
Service Level:     Standard
Service Type:      L1-L3
Status Details:    
Starts:            08/08/2013
Ends:              08/08/2014


Actual results:
Quantity Used:     2

Expected results:
Quantity Used:     1

Additional info:



[root@localhost ~]# subscription-manager attach --auto
Installed Product Current Status:
Product Name: Awesome OS Instance Server Bits
Status:       Subscribed

[root@localhost ~]# subscription-manager list --consumed
+-------------------------------------------+
   Consumed Subscriptions
+-------------------------------------------+
Subscription Name: Awesome OS Instance Based (Standard Support)
Provides:          Awesome OS Instance Server Bits
SKU:               awesomeos-instancebased
Contract:          42
Account:           12331131231
Serial:            4495643599020139101
Pool ID:           8ac6a3a2405c7fed01405c80f7f50808
Active:            True
Quantity Used:     1
Service Level:     Standard
Service Type:      L1-L3
Status Details:    
Starts:            08/08/2013
Ends:              08/08/2014

Comment 1 Devan Goodwin 2013-08-09 13:48:59 UTC
Caused by issue very similar to: https://bugzilla.redhat.com/show_bug.cgi?id=921249

Facts are loaded for the first time in a thread, which tries to call virt-who causing this error:

   signal.signal(signal.SIGPIPE, signal.SIG_DFL)
ValueError: signal only works in main thread

As a result the is_guest setting is set to Unknown on the server when firstboot runs, which causes server to assume physical and thus recommend 2 instance ents. 

Need to make sure we load the facts before entering async threaded code. Patching now.

Comment 2 Devan Goodwin 2013-08-12 11:48:46 UTC
Fixed in subscription-manager master: 2f90b18ecd800051f3db65df2e928ec01fd9cf59

Adding flags for a 5.10 blocker/exception as this is probably bad enough to warrant a fix. Initial instance subscriptions for a virt system registering through firstboot will be much larger than they should be.

Comment 5 John Sefler 2013-08-13 22:40:54 UTC
Created attachment 786325 [details]
only 1 entitlement from an instance based subscription is required for compliance for a virt guest  during firstboot

Verifying Version....
[root@jsefler-5 ~]# subscription-manager version
server type: This system is currently not registered.
subscription management server: 0.8.18-1
subscription-manager: 1.8.19-1.el5
python-rhsm: 1.8.16-1.el5

[root@jsefler-5 ~]# subscription-manager list --installed
+-------------------------------------------+
    Installed Product Status
+-------------------------------------------+
Product Name:   Awesome OS Instance Server Bits
Product ID:     32060
Version:        6.1
Arch:           ALL
Status:         Unknown
Status Details: 
Starts:         
Ends:           

[root@jsefler-5 ~]# echo '{"virt.is_guest":"True", "cpu.cpu_socket(s)":"22"}' > /etc/rhsm/facts/custom.facts
[root@jsefler-5 ~]# firstboot -r

Within firstboot, I registered as testuser1/password/admin and the firstboot summary panel shows that only 1 entitlement will be granted.  See screenshot.

[root@jsefler-5 ~]# subscription-manager list --consumed
+-------------------------------------------+
   Consumed Subscriptions
+-------------------------------------------+
Subscription Name: Awesome OS Instance Based (Standard Support)
Provides:          Awesome OS Instance Server Bits
SKU:               awesomeos-instancebased
Contract:          43
Account:           12331131231
Serial:            353597039602752197
Pool ID:           8a90f84a4035a6cb014035a82e0e051d
Active:            True
Quantity Used:     1
Service Level:     Standard
Service Type:      L1-L3
Status Details:    
Starts:            07/30/2013
Ends:              07/30/2014


Moving to VERIFIED

Comment 7 errata-xmlrpc 2013-09-30 23:16:02 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1332.html