Bug 1305773
| Summary: | Changing Content View of a Content Host needs to better inform the user around client needs | |||
|---|---|---|---|---|
| Product: | Red Hat Satellite | Reporter: | Pavel Moravec <pmoravec> | |
| Component: | Hosts - Content | Assignee: | Chris Roberts <chrobert> | |
| Status: | CLOSED ERRATA | QA Contact: | Stephen Wadeley <swadeley> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 6.1.6 | CC: | ahumbe, aupadhye, bbuckingham, chrobert, jjeffers, jsherril, mlele, pcreech, pmoravec, sthirugn, swadeley | |
| Target Milestone: | 6.7.4 | Keywords: | PrioBumpGSS, Reopened, Triaged | |
| Target Release: | Unused | |||
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | tfm-rubygem-katello-3.14.0.28-1 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1874160 (view as bug list) | Environment: | ||
| Last Closed: | 2020-09-30 13:12:09 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: | ||||
|
Description
Pavel Moravec
2016-02-09 08:34:30 UTC
Moving 6.2 bugs out to sat-backlog. I do not believe this request is valid. Satellite 6.1 (and later) calculates errata status based off the Library instance of all that host's repositories. This way we can detect if errata are applicable even if they aren't in that host's content view and lifecycle environment. All requests for errata that are installable for a content host are calculated based off that information. So moving a host from content view to content view ore lifecycle environment to lifecycle environment should not affect the data that is stored at all. I'm curious if there was some issue you were encountering that encouraged this BZ. None of the above was true for 6.0 and this would be a valid request for 6.0 (if we were still patching it). In another words: Content View change does not update RHSM config on the client (what would update applicability on Sat itself). Assume I have 2 content views, each for a different product plus RHEL base repo. And a client machine is assigned to one CV. It can apply errata from that CV and nobody knows what errata from 2nd CV are applicable to it. Now I change CV for the client to the second one - just in WebUI. Clicking now to errata page, I still see errata from old CV / old product are applicable to the client. And I can apply the errata from old CV to a client assigned to a new CV. But errata from the newly assigned CV are not applicable to the client. If I manually execute e.g. "subscription-manager repos --list" on the client, the client's /etc/yum.repos.d/redhat.repo is updated to the new CV paths, and just even since now I can see errata from new CV /new product are applicable to the client. I heard RHSM / subscription-manager does similar check to update repos periodically, so if I wait say a day, proper errata would be seen as applicable - was I just too impatient? Ahhh, so you are correct, i did forget about one aspect. We currently 'mark' the current repos that the client is using based on what it tells us and that would be wrong until a sub-man refresh and yum action occurs. We likely could update a client's repos using assumptions based on what they are currently using. It may not be 100% accurate but would be more accurate than continuing to use old data. Created redmine issue http://projects.theforeman.org/issues/17798 from this bug (In reply to Justin Sherrill from comment #8) > Ahhh, so you are correct, i did forget about one aspect. We currently > 'mark' the current repos that the client is using based on what it tells us > and that would be wrong until a sub-man refresh and yum action occurs. > > We likely could update a client's repos using assumptions based on what they > are currently using. It may not be 100% accurate but would be more accurate > than continuing to use old data. I just realized that only updating the reg.applicability data on Satellite are not enough. Since it allows to apply new errata from new repos that the client machine is not aware of yet - it would be after running sub-man refresh or so. Therefore this action (changing C.V. of a Content Host) shall somehow update the client as well, i.e. by invoking (via REX? or goferd?) sub-man refresh. And _this_ action will trigger reg.app task on Satellite, so _this_ should be imho the proper fix: C.V. change needs to trigger sub-man refresh on the client. Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you. Reopening due to the number of customer cases. The scope of the bug should be limited to: 1. Displaying message that 'yum clean all' and 'subscription-manager refresh' should be performed on all clients Further, we could: 2. Re-set the bound repos for the host(s) to match the newly set CV/LCE A future enhancement that will likely not be as part of this bz would be to: 3. Link to a remote execution job to run these two commands on the changed host(s) The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Red Hat Technical Support or your account team. If we do not hear from you, we will close this bug out. Thank you. Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you. Hi Pavel, I have added a info box in the UI for a sinble host and bulk hosts to run the commands Justin suggested on comment #12 Here are the pictures: https://nimbusweb.me/s/share/4436937/wzoolhiosxb1bh7socuf https://nimbusweb.me/s/share/4436934/gh996fooe0n0x141qmuh Let me know if that is enough to satisfy this bz and close it? My worry about generating an applicability task for each host, is the performance side of things if you kicked off that task on 50k+ hosts - Chris Roberts Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/17798 has been resolved. Thank you Chris for getting this long time request done. I think: - It is confusing when you say `new Content View` as sometimes the Content view may be old and reused - We can remove the `Please` and just start with the instructions. Can I propose the following changes: Content Host page: ``` Note: Updating the content view here will not automatically update the client. Run the following commands on the client for the content view changes to take effect. # yum clean all # subscription-manager refresh ``` Content Host Bulk Content page: - Move this note to the bottom of the page rather than in the top so it makes logical sense. Right now, it feels like you are asking me to do this on the client before doing this on the Satellite. ``` Note: Updating the content view here will not automatically update the client. Run the following commands on the client for the content view changes to take effect. # yum clean all # subscription-manager refresh ``` +1 for the Suresh's proposal. 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 (Important: Satellite 6.7.4 Async Bug Fix Update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:4127 |