Hide Forgot
Description of problem: After using compliance assistant to become compliant for a date in the future, the "complaint until" date does not change, even after a restart of the GUI. Version-Release number of selected component (if applicable): subscription-manager-0.96.5-1 plus a fix for bug #710149 How reproducible: Unsure. Steps to Reproduce: 1. Against a test Candlepin with the normal test data, setup a client system with one product cert installed. I used "Awesome OS Server Bits". 2. Bind a subscription for today with All Available Subscriptions tab. 3. Note that compliance assistant portion of the UI in the top left now shows green checkmark, and product entitlements valid until about a year from today. 4. Click the Update Certificates button. 5. Select the product that will be out of compliance, and bind to one of the resulting subscriptions to get yourself compliant for the date a year from now. 6. Return to main screen. Actual results: The compliant until date still says a year from now (2012), when in fact it should be two years from now as we have another entitlement to cover us on that date. If you launch the compliance assistant, it cannot find any products that will not be compliant on the date in question. Expected results: Compliant until date should be the first date we're not compliant. (2013 in this case, when the second entitlement expires) Additional info: Note that this requires the fix for bug #710149, otherwise the compliance assistant button is not visible once you're compliant today. (step 2) This is most likely a problem with certlib.py find_first_invalid_date.
Fixed in subscription-manager.git master: 557d30e19ab040518cd5ac4ba7eea087adea2d6c Some notes on behavior changes from commit message: Behavior now changes for systems with no product certs installed. Subscription assistant cannot be used in this case (the middle pane lets you select from installed products). find_first_invalid_date will now return None in this case, as there is no first invalid date. New find_first_invalid_date implementation: - return None if no products installed. (GUI updated to handle this) - if out of compliance today, return current date time. - otherwise: - sort all entitlement certs (including those for future) by end date - loop through each cert's end date, check compliance on that date until we find one where we're out of compliance. - now re-uses CertSorter logic to do this.
Created attachment 524764 [details] Update Certificates button is removed when no products are installed Version... [root@jsefler-onprem-62server ~]# rpm -qa | grep subscription-manager subscription-manager-0.96.11-1.git.7.15fc9d2.el6.x86_64 subscription-manager-firstboot-0.96.11-1.git.7.15fc9d2.el6.x86_64 subscription-manager-gnome-0.96.11-1.git.7.15fc9d2.el6.x86_64 In response to Devan's behavior note in comment 1, if there are no products installed, then the Update Certificates button is actually removed and the Subscription Assistant window cannot be opened to see "None" listed as the first date of non compliance. This seems reasonable since there are no products installed in need for subscription assistance. [root@jsefler-onprem-62server ~]# subscription-manager list --installed No installed Products to list
Created attachment 524765 [details] Screenshot shows correct compliance dates when no installed products are subscribed. To complete the test in comment 4, notice in the screenshot that when there is a product installed (but not subscribed), the "Software entitlements valid until <DATE>" is today. Today is also displayed as the "first date of invalid entitlements". Both of these are true statements since we really don't care about the past. Today and the future are what matter and today is the first date that we care about being in-compliant. [root@jsefler-onprem-62server ~]# date Sat Sep 24 23:29:03 EDT 2011 [root@jsefler-onprem-62server ~]# This verifies Devan's statement "if out of compliance today, return current date time."
Created attachment 524766 [details] product entitlement cert valid until the end date of the first subscribe Now, let's verify the original bug... 1. With one product installed (Awesome OS Server Bits / 37060.pem), use the subscription assistant to become compliant today. Now you can see in the following list (and the screenshot) that we are consuming one subscription that is covers compliance today (9/25/2011) through the end of the subscription on 10/21/2012 [root@jsefler-onprem-62server ~]# subscription-manager list --consumed +-------------------------------------------+ Consumed Product Subscriptions +-------------------------------------------+ ProductName: Awesome OS Server Bits ContractNumber: 7 AccountNumber: 12331131231 SerialNumber: 5396129095677455570 Active: True QuantityUsed: 1 Begins: 08/22/2011 Expires: 10/21/2012 [root@jsefler-onprem-62server ~]# subscription-manager list --installed +-------------------------------------------+ Installed Product Status +-------------------------------------------+ ProductName: Awesome OS Server Bits Version: 6.1 Arch: ALL Status: Subscribed Starts: 08/22/2011 Expires: 10/21/2012 [root@jsefler-onprem-62server ~]#
Created attachment 524767 [details] After subscribing to a future subscription, we are now compliant through the length of two subscriptions that overlap in coverage 2. Now, using the subscription assistant we can subscribe to a pool that provides coverage on the "first date of invalid entitlements". After doing so, we are now covered by two subscriptions that overlap in time and the date in the upper left corner of the Certificate Status shows the final end date of the future subscription (see screenshot). This is now correct and VERIFIES the original problem in comment 0. The following shows the overlapping dates of coverage... [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
Created attachment 524768 [details] My Installed Products fails to roll up the subscription dates that cover this product HOWEVER.... Now that we are subscribed to two overlapping subscriptions that cover the same product, the following list installed neglects to roll up the status. In facts it displays the start/end date of the the subscription that covers it today from comment 6 and displays the status of the second subscription from comment 7 which is a Future subscription. That's messed up. The same is true in the GUI. See screenshot. [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 THIS SHOULD BE OPENED AS A NEW BUG A suggestion for expected output for the CLI and GUI 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 Where the Expires date is found using the find_first_invalid_date algorithm referenced by Devan in comment 1 against subscriptions that provide this product.
Created attachment 524828 [details] Certificate Status properly handles a far future subscription after a break in coverage. 3. Finally to further test Devan's find_first_invalid_date algorithm, let's create a future subscription that does NOT overlap the first two subscriptions that provide coverage for our installed product. On a time line, we will have something that looks like this... SerialNumber: 5396129095677455570 =================== SerialNumber: 5475269785960299353 =================== SerialNumber: =================== | | | | | today 1yr 2yr ... 5yr 6yr Here is how I Create the non-overlapping third subscription in the far future... [root@jsefler-onprem-62server ~]# curl -k --user admin:admin --request POST --data '{"product":{"id":"awesomeos-server-basic"},"startDate":"Tue, 13 Sep 2016 01:00:00 -0400","accountNumber":123456,"quantity":20,"endDate":"Wed, 13 Sep 2017 01:00:00 -0400","contractNumber":123,"providedProducts":[{"id":"37060"}]}' --header 'accept: application/json' --header 'content-type: application/json' https://jsefler-onprem-62candlepin.usersys.redhat.com:8443/candlepin/owners/admin/subscriptions | python -mjson.tool % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 107 4192 102 4192 0 227 23733 1285 --:--:-- --:--:-- --:--:-- 58308 { "accountNumber": "123456", "certificate": null, "contractNumber": "123", "created": "2011-09-26T01:50:30.949+0000", "endDate": "2017-09-13T05:00:00.000+0000", "id": "8a90f8c6329990ae0132a36d2225134f", "modified": null, "owner": { "displayName": "Admin Owner", "href": "/owners/admin", "id": "8a90f8c6329990ae013299911afb0006", "key": "admin" }, "product": { "attributes": [ { "created": "2011-09-24T03:53:54.542+0000", "name": "version", "updated": "2011-09-24T03:53:54.542+0000", "value": "1.0" }, { "created": "2011-09-24T03:53:54.542+0000", "name": "variant", "updated": "2011-09-24T03:53:54.542+0000", "value": "ALL" }, { "created": "2011-09-24T03:53:54.542+0000", "name": "support_type", "updated": "2011-09-24T03:53:54.542+0000", "value": "Self-Support" }, { "created": "2011-09-24T03:53:54.542+0000", "name": "sockets", "updated": "2011-09-24T03:53:54.542+0000", "value": "2" }, { "created": "2011-09-24T03:53:54.542+0000", "name": "arch", "updated": "2011-09-24T03:53:54.542+0000", "value": "ALL" }, { "created": "2011-09-24T03:53:54.542+0000", "name": "management_enabled", "updated": "2011-09-24T03:53:54.542+0000", "value": "0" }, { "created": "2011-09-24T03:53:54.542+0000", "name": "type", "updated": "2011-09-24T03:53:54.542+0000", "value": "MKT" }, { "created": "2011-09-24T03:53:54.542+0000", "name": "support_level", "updated": "2011-09-24T03:53:54.542+0000", "value": "None" }, { "created": "2011-09-24T03:53:54.542+0000", "name": "warning_period", "updated": "2011-09-24T03:53:54.542+0000", "value": "30" }, { "created": "2011-09-24T03:53:54.542+0000", "name": "multi-entitlement", "updated": "2011-09-24T03:53:54.542+0000", "value": "no" } ], "created": "2011-09-24T03:53:54.541+0000", "dependentProductIds": [], "href": "/products/awesomeos-server-basic", "id": "awesomeos-server-basic", "multiplier": 1, "name": "Awesome OS Server Basic", "productContent": [], "updated": "2011-09-24T03:53:54.541+0000" }, "providedProducts": [ { "attributes": [ { "created": "2011-09-24T05:44:54.166+0000", "name": "variant", "updated": "2011-09-24T05:44:54.166+0000", "value": "ALL" }, { "created": "2011-09-24T05:44:54.166+0000", "name": "sockets", "updated": "2011-09-24T05:44:54.166+0000", "value": "2" }, { "created": "2011-09-24T05:44:54.166+0000", "name": "arch", "updated": "2011-09-24T05:44:54.166+0000", "value": "ALL" }, { "created": "2011-09-24T05:44:54.166+0000", "name": "type", "updated": "2011-09-24T05:44:54.166+0000", "value": "SVC" }, { "created": "2011-09-24T05:44:54.166+0000", "name": "warning_period", "updated": "2011-09-24T05:44:54.166+0000", "value": "30" }, { "created": "2011-09-24T05:44:54.166+0000", "name": "version", "updated": "2011-09-24T05:44:54.166+0000", "value": "6.1" } ], "created": "2011-09-24T03:53:50.035+0000", "dependentProductIds": [], "href": "/products/37060", "id": "37060", "multiplier": 1, "name": "Awesome OS Server Bits", "productContent": [ { "content": { "contentUrl": "/foo/path/never", "created": "2011-09-24T03:53:41.540+0000", "gpgUrl": "/foo/path/never/gpg", "id": "0", "label": "never-enabled-content", "metadataExpire": 600, "modifiedProductIds": [], "name": "never-enabled-content", "requiredTags": null, "type": "yum", "updated": "2011-09-24T03:53:41.540+0000", "vendor": "test-vendor" }, "enabled": false }, { "content": { "contentUrl": "/foo/path/always", "created": "2011-09-24T03:53:41.757+0000", "gpgUrl": "/foo/path/always/gpg", "id": "2", "label": "tagged-content", "metadataExpire": null, "modifiedProductIds": [], "name": "tagged-content", "requiredTags": "TAG1,TAG2", "type": "yum", "updated": "2011-09-24T03:53:41.757+0000", "vendor": "test-vendor" }, "enabled": true }, { "content": { "contentUrl": "/foo/path/always", "created": "2011-09-24T03:53:41.669+0000", "gpgUrl": "/foo/path/always/gpg", "id": "1", "label": "always-enabled-content", "metadataExpire": 200, "modifiedProductIds": [], "name": "always-enabled-content", "requiredTags": null, "type": "yum", "updated": "2011-09-24T03:53:41.669+0000", "vendor": "test-vendor" }, "enabled": true }, { "content": { "contentUrl": "/foo/path", "created": "2011-09-24T03:53:41.864+0000", "gpgUrl": "/foo/path/gpg/", "id": "1111", "label": "content-label", "metadataExpire": 0, "modifiedProductIds": [], "name": "content", "requiredTags": null, "type": "yum", "updated": "2011-09-24T03:53:41.864+0000", "vendor": "test-vendor" }, "enabled": true } ], "updated": "2011-09-24T03:53:50.035+0000" } ], "quantity": 20, "startDate": "2016-09-13T05:00:00.000+0000", "updated": "2011-09-26T01:50:30.949+0000", "upstreamPoolId": null } Refreshing pools so that it will become available to my system... [root@jsefler-onprem-62server ~]# curl -k --user admin:admin --request PUT https://jsefler-onprem-62candlepin.usersys.redhat.com:8443/candlepin/owners/admin/subscriptions | python -mjson.tool % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 122 366 122 366 0 0 2840 0 --:--:-- --:--:-- --:--:-- 9384 { "created": "2011-09-26T01:52:11.070+0000", "finishTime": null, "group": "async group", "id": "refresh_pools_a3d99f5f-dd5f-48ae-a209-2f60259035c5", "principalName": "admin", "result": null, "startTime": null, "state": "CREATED", "statusPath": "/jobs/refresh_pools_a3d99f5f-dd5f-48ae-a209-2f60259035c5", "targetId": "admin", "targetType": "owner", "updated": "2011-09-26T01:52:11.070+0000" } [root@jsefler-onprem-62server ~]# Now I can use the CLI to list --avail --ondate or use the GUI the search ondate 01/01/2017 [root@jsefler-onprem-62server ~]# subscription-manager list --avail --ondate 2017-01-01 +-------------------------------------------+ Available Subscriptions +-------------------------------------------+ ProductName: Awesome OS Server Basic ProductId: awesomeos-server-basic PoolId: 8a90f8c6329990ae0132a36eab981350 Quantity: 20 Multi-Entitlement: No Expires: 09/13/2017 MachineType: physical [root@jsefler-onprem-62server ~]# subscription-manager subscribe --pool=8a90f8c6329990ae0132a36eab981350 Successfully subscribed the system to Pool 8a90f8c6329990ae0132a36eab981350 [root@jsefler-onprem-62server ~]# Now I am consuming three subscriptions that cover my installed product... [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: 123 AccountNumber: 123456 SerialNumber: 3927644240804705755 Active: True QuantityUsed: 1 Begins: 09/13/2016 Expires: 09/13/2017 ProductName: Awesome OS Server Bits ContractNumber: 7 AccountNumber: 12331131231 SerialNumber: 5396129095677455570 Active: True QuantityUsed: 1 Begins: 08/22/2011 Expires: 10/21/2012 [root@jsefler-onprem-62server ~]# Now let's look at the GUI and we should see that despite the third far future subscription, the first date of incompliance should be the end of the second subscription. (See the screenshot) YES! Devan's implemented algorithm is working.
After opening bug 741155 to address the issues in comment 8, I am moving this bug to VERIFIED.
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-2011-1695.html