Hide Forgot
Created attachment 524834 [details] the status/starts/expires data for an installed product is currently wrong when multiple providing subscriptions are being consumed Description of problem: When subscribed to multiple subscriptions that provide coverage for a common installed product, the GUI and CLI display a status along with a start date and end date for the coverage. The problem is that when these multiple consumed subscriptions span different coverage periods for the installed product, the status and dates neglect to roll-up a summary of the coverage. For example, if today is 9/25/2011 and I have one product installed (Awesome OS Server Bits), I can subscribe to a pool that provides coverage today and expires in about 1 yr. Then I can also subscribe to a future pool that provides coverage starting a year from now ending in about two years. My installed product is now compliant for the next two years. My consumed subscriptions look like this... [root@jsefler-onprem-62server ~]# subscription-manager list --consumed +-------------------------------------------+ Consumed Product Subscriptions +-------------------------------------------+ ProductName: Awesome OS Server Bits ContractNumber: 7 AccountNumber: 12331131231 SerialNumber: 5475269785960299353 Active: True QuantityUsed: 1 Begins: 09/11/2012 Expires: 09/11/2013 ProductName: Awesome OS Server Bits ContractNumber: 7 AccountNumber: 12331131231 SerialNumber: 5396129095677455570 Active: True QuantityUsed: 1 Begins: 08/22/2011 Expires: 10/21/2012 ^^^ Notice the overlapping dates of coverage. That's fine. It provides continuous compliance. Now let's look at the list installed in the CLI (or see screenshot for the GUI)... [root@jsefler-onprem-62server ~]# subscription-manager list --installed +-------------------------------------------+ Installed Product Status +-------------------------------------------+ ProductName: Awesome OS Server Bits Version: 6.1 Arch: ALL Status: Future Subscription Starts: 08/22/2011 Expires: 10/21/2012 ^^^ The "Future Subscription" status certainly does not match the start/expires dates which cover today's subscription. This is wrong. The list installed is failing to roll-up an overall status from the multiple consumed subscriptions. It should also report a union of the dates up to the first date of non-compliance. A suggestion for the expected output for the above example could be... +-------------------------------------------+ Installed Product Status +-------------------------------------------+ ProductName: Awesome OS Server Bits Version: 6.1 Arch: ALL Status: Multiple Subscriptions Starts: 08/22/2011 Expires: 09/11/2013 Version-Release number of selected component (if applicable): [root@jsefler-onprem-62server ~]# rpm -q subscription-manager subscription-manager-0.96.11-1.git.7.15fc9d2.el6.x86_64 How reproducible: Steps to Reproduce: See bug 727967 comments 6thru8 https://bugzilla.redhat.com/show_bug.cgi?id=727967#c6 https://bugzilla.redhat.com/show_bug.cgi?id=727967#c7 https://bugzilla.redhat.com/show_bug.cgi?id=727967#c8
The solution to this problem (what installed status and coverage dates to report for an installed product) is not obvious because the status is really a function of date and depends on what subscriptions/quantity are subscribed over the course of time. Possibilities: - the status for the installed product could be for today only. - the status for the installed product could be ambiguous (Multiple Subscriptions) as suggested in comment 0 - the dates could be a union of subscription dates up to the first day of no coverage - the dates could be wrong no matter what status we choose to report - we could remove the dates
I think the reporting of future subscribed is fixed, but the dates on the list installed are not. Also I do not think we're properly accounting for the possibility that the system is not in compliance somewhere between the earlier start date of an entitlement for this product, and the latest end date for an entitlement of this product. I.e. you might be compliant from 2011 - 2012, then from 2020-2021, but we'd list you as compliant from 2011 - 2021, which is far from the case.
Fix committed to master branch: 0b197c8b5e608708550c95c510537ce5992aeb81 NOTE: Although the fix is in the commit above, it is broken in RHEL6 due to a difference in python versions (API change). This has been addressed by commit 97f757a70216c402536220bfc58cf13bd71cfb27 in the master branch. When testing on RHEL6 please be sure that both commits are included in the version of subscription-manager. If you are using 0.99.7-1+ you are Ok.
Moving to verified RPM used: [root@kvm-guest-04 product]# subscription-manager list --consumed +-------------------------------------------+ Consumed Product Subscriptions +-------------------------------------------+ Product Name: Awesome OS Workstation Bits Contract Number: 25 Account Number: 12331131231 Serial Number: 4578808357493136203 Active: True Quantity Used: 1 Service Level: Standard Service Type : L1-L3 Begins: 03/18/2012 Expires: 03/18/2013 Product Name: Awesome OS Workstation Bits Contract Number: 25 Account Number: 12331131231 Serial Number: 7587081658217073831 Active: False Quantity Used: 1 Service Level: Standard Service Type : L1-L3 Begins: 03/08/2013 Expires: 03/08/2014 [root@kvm-guest-04 product]# subscription-manager list --installed +-------------------------------------------+ Installed Product Status +-------------------------------------------+ Product Name: Awesome OS Workstation Bits Version: 6.1 Arch: ALL Status: Subscribed Starts: 03/18/2012 Expires: 03/08/2014
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-2012-0804.html