Problem:
On my new Katello 4.5 installation I have noticed that my three client hosts (the katello server itself and two smart proxies) all report applicable errata which is not installable. For instance, they all report “FEDORA-EPEL-2019-8b0678313a”, i.e. rubygem-gssapi applicable but not installable.
rubygem-gssapi is part of foreman 3.3 and epel8 repositories.
All three hosts are have a content view assigned which includes a filtered view on EPEL 8, because I need a few hand-picked rpms from EPEL 8 for our monitoring. But the filtered view does not contain rubygem-gssapi and a few more rpms which are available through the foreman or pulp repos.
So Katello seems to think there are applicable errata from EPEL 8 because the hosts have EPEL 8 enabled, even though the assigned content view does not contain any of those RPMs which are part of the errata.
Expected outcome:
In my opinion, a errata should not be reported applicable if none of the packages in the errata are actually available in the content view because of filtering.
Or in other words: a host with a content view which only consists of include filters should only consider errata applicable which contain packages included in the filter, because all other errata from that repositories won’t ever be installable.
Foreman and Proxy versions:
Foreman 3.3, Katello 4.5
Applicable errata: any errata Katello knows about that contains packages installed on your host. Installable errata: any errata that is applicable AND able to be installed because your host has access to it via content view / environment.
The only one of the above that changes based on content views and filters should be installable errata. I feel like modifying the definition of applicable in this way could get very confusing, because then both applicable and installable errata could change by modifying a content view.
The sounds like an errata is applicable even if the repository isn’t even enabled. Is that right? I can’t test it right now but if I would disable EPEL 8 it would still be applicable errata?
Ok. But then at least the host status shouldn’t be on warning if the errata can never be applied because the repository is not in the content view or the package is filtered out. Currently my three foreman servers all have warning status because erratas are applicable which, however, never can be applied until foreman repos provide updates.
Just tested it: after I disable the EPEL 8 repository and do a “dnf uploadprofile” there a no applicable errata anymore.
@jeremylenz So basically it seems, katello calculates applicable errata on all enabled repositories without considering filters. That is not what I would expect. But it’s also not as broad as your definition before.
IMHO an errata in a enabled repository can only be applicable if the (at least one of) packages in the errata are accessible in the content view assigned.
Or is there another way to achieve what I want to do, which is providing access to a few hand-picked rpms in epel8 including future updates?
Interesting. But it actually makes sense, because I know that filters are applied only at runtime when publishing content views; the results of the filters aren’t actually stored anywhere.
Now that I understand a bit better I’d say you could file a Redmine with that RFE to take filters into account when calculating applicable errata…
