Bug 994997 - It takes 2 instance based subscriptions to make a virt-system compliant on firstboot
It takes 2 instance based subscriptions to make a virt-system compliant on fi...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: subscription-manager (Show other bugs)
5.10
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: John Sefler
IDM QE LIST
:
Depends On:
Blocks: rhsm-rhel510
  Show dependency treegraph
 
Reported: 2013-08-08 07:35 EDT by Shwetha Kallesh
Modified: 2013-09-30 19:16 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
No description necessary
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-30 19:16:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
2 quantities of instance based subscription (91.44 KB, image/png)
2013-08-08 07:35 EDT, Shwetha Kallesh
no flags Details
only 1 entitlement from an instance based subscription is required for compliance for a virt guest during firstboot (120.57 KB, image/png)
2013-08-13 18:40 EDT, John Sefler
no flags Details

  None (edit)
Description Shwetha Kallesh 2013-08-08 07:35:13 EDT
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 09:48:59 EDT
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 07:48:46 EDT
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 18:40:54 EDT
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 19:16:02 EDT
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

Note You need to log in before you can comment on or make changes to this bug.