Bug 676371
| Summary: | Compliance Assistant closes when you're not done | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | J.C. Molet <jmolet> | ||||||||
| Component: | subscription-manager | Assignee: | Chris Duryee <cduryee> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | J.C. Molet <jmolet> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 6.1 | CC: | cduryee, dgoodwin | ||||||||
| 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: | 2011-05-19 13:39:39 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: | 568421 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
J.C. Molet
2011-02-09 16:35:54 UTC
fixed in master 0.96.2+, 7e2d849 fixed in RHEL6 branch 0.95.2+, f6056bd Tested working as of version: subscription-manager-0.95.1-1.git.15.c75e560.el6.x86_64 subscription-manager-gnome-0.95.1-1.git.15.c75e560.el6.x86_64 subscription-manager-firstboot-0.95.1-1.git.15.c75e560.el6.x86_64 python-rhsm-0.95.3-1.git.0.4d0ef8e.el6.noarch This works at first, and the list is reduced as your products become in compliance. I tested this with products that did and did not have matching subscriptions. The list would whittle away until only the products that did not have available subscriptions were left. This works as expected. I then tested another case: - I deleted the products that did not have subscriptions (and therefore could never be in compliance) out of the /etc/pki/products folder to simulate these things not being installed. - This left me a set that could theoretically place me in 100% compliance. - I re-registered. - I opened the compliance assistant. - I checked all the boxes and one by one subscribed to products to become in compliance. After the last one I expected the list of non-compliant products to either be blank, or the compliance assistant to close. This did not happen. - What happened then was the entire list of all my products repopulated itself (see first following screenshot) - I was able to subscribe to some of these again and it was marked as a future subscription (see second screenshot) - It returned subscriptions that I was not able to subscribe to at all (see third screenshot) Created attachment 479544 [details]
in compliance?
This is what happens after all products are in compliance.
Created attachment 479545 [details]
in compliance? 2
Some subscriptions are able to be subscribed to as "future entitlements"
Created attachment 479546 [details]
in compliance? 3
Some subscriptions you already are subscribed to.
Screenshots 1 and 2 look right, the compliance assistant is re-calculating the default date based on when you'll next be non-compliant as soon as you open it. In a sense you can never be compliant forever so the assistant should always be openable, it's just a matter of what date it tries to start getting you compliant. Screenshot 3 looks bad, I believe this is related to the fix above though, what happens is you hit Subscribe, but now that we keep the assistant open there is no graphical indication that it worked, everything just looks the same. This is very easy to mistake, you think you must have failed to hit the button and press it again, and now you get an error because your original attempt was successful, and now you're trying to bind to the same pool again. In the original fix, after we subscribe a call was added to check for date change, which would trigger a refresh of the screen if the date has changed. In our case however the date has not changed, but we still need to refresh the screen as our compliance state has changed on the date in question, and we no longer want to see the subscription we just bound to. Proposed fix is to just call refresh_screen after bind. Will check in with Chris and make sure this is ok. Fixed in master: 70d7ce00e32f94674e8ce6c14bb16b30d63341d1 (should appear in subscription-manager-0.96.2) Ported to RHEL6: 4ec14b7619b913d30c9442610445ceae1333d201 (should appear in subscription-manager-0.95.4) This works now in: subscription-manager-0.95.4-1.git.0.1fb5ee4.el6.x86_64 python-rhsm-0.95.4-1.git.0.1189f1a.el6.noarch subscription-manager-gnome-0.95.4-1.git.0.1fb5ee4.el6.x86_64 subscription-manager-firstboot-0.95.4-1.git.0.1fb5ee4.el6.x86_64 Subscription manager stays open and displays valid products and subscriptions until the candlepin server no longer has anything new to show me. Marking VERIFIED. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2011-0611.html |