Red Hat Bugzilla – Bug 1305773
Changing Content View of a Content Host needs to trigger GenerateApplicability task automatically
Last modified: 2017-08-29 10:14:43 EDT
Description of problem:
When changing Content View of a Content Host, the WebUI shows wrong applicable errata relevant to the previous Content View. This information should be updated automatically.
Currently, the user has to workaround it by running "subscription-manager refresh" on the host. That does several local changes on the host and runs Actions::Katello::System::GenerateApplicability task in Satellite.
Ideally, both should be done automatically once one changes C.V. in Satellite. The question is how a change in Satellite can update RHSM stuff on the host (via katello-agent/goferd?). But at least the GenerateApplicability task should be kicked off automatically.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Have a Content Host in some Content View such that some errata is applicable to the Host.
2. Change Host's C.V. to some empty C.V. (or some C.V. where _different_ errata is applicable)
3. Check if/what errata is applicable.
4. (optionally, try yum update on the host - shall Sat update RHSM stuff like "subscription-manager refresh" does automatically as well?)
3. errata from past C.V. are shown to be applicable
4. yum update will try to get updates from _past_ C.V.
3. errata from current C.V. are shown
4. yum update to try getting updates from _new_ C.V.
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.