Bug 1305773 - Changing Content View of a Content Host needs to trigger GenerateApplicability task automatically
Changing Content View of a Content Host needs to trigger GenerateApplicabilit...
Status: NEW
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Hosts - Content (Show other bugs)
6.1.6
x86_64 Linux
medium Severity medium (vote)
: Unspecified
: --
Assigned To: Justin Sherrill
Katello QA List
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-09 03:34 EST by Pavel Moravec
Modified: 2017-08-29 10:14 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Foreman Issue Tracker 17798 None None None 2016-12-20 09:08 EST
Red Hat Knowledge Base (Solution) 2024463 None None None 2017-08-29 05:11 EDT

  None (edit)
Description Pavel Moravec 2016-02-09 03:34:30 EST
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:
Comment 3 Bryan Kearney 2016-08-04 16:14:19 EDT
Moving 6.2 bugs out to sat-backlog.
Comment 4 Justin Sherrill 2016-12-19 13:51:04 EST
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).
Comment 6 Pavel Moravec 2016-12-20 06:59:09 EST
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?
Comment 8 Justin Sherrill 2016-12-20 09:07:43 EST
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.
Comment 9 Justin Sherrill 2016-12-20 09:08:25 EST
Created redmine issue http://projects.theforeman.org/issues/17798 from this bug
Comment 10 Pavel Moravec 2016-12-20 11:54:09 EST
(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.

Note You need to log in before you can comment on or make changes to this bug.