Project

General

Profile

Bug #17798

Changing Content View of a Content Host needs to trigger GenerateApplicability task automatically

Added by Justin Sherrill over 2 years ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Category:
Hosts
Target version:
Difficulty:
Triaged:
Yes
Bugzilla link:
Pull request:
Team Backlog:
Fixed in Releases:
Found in Releases:

Description

Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1305773

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):
Sat 6.1.6

How reproducible:
100%

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?)

Actual results:
3. errata from past C.V. are shown to be applicable
4. yum update will try to get updates from past C.V.

Expected results:
3. errata from current C.V. are shown
4. yum update to try getting updates from new C.V.

Additional info:

History

#1 Updated by Pavel Moravec over 2 years ago

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.

#2 Updated by Justin Sherrill over 2 years ago

  • Legacy Backlogs Release (now unused) set to 114

Also available in: Atom PDF