Bug #35016
openNot-installable errata can appear as installable
Description
This community post uncovered this issue: https://community.theforeman.org/t/installable-errata-suddenly-shows-up-in-hosts-content-view-but-not-installable-via-content-view/28787/13
Basically, Katello will exclude an erratum from a CVV repo if the erratum is incomplete. That exclusion will not occur if the Library source repo doesn't hold the missing RPMs. That is expected. However, this becomes an issue in the case of Rocky Linux with filters (and maybe even RHEL 8, but I couldn't find an example). RLSA-2021:3666 in Rocky Linux 8 exists in both AppStream and BaseOS. However, the c-ares RPMs don't exist in AppStream, only BaseOS. So when the CV copy code gets to copying content for AppStream, even if c-ares is excluded, the erratum will be included. This isn't necessarily an issue, however, it means that the erratum will show up as installable if it is also applicable. That's the bug. Granted, this scenario might be caused by Rocky Linux doing weird things with its errata, but we can't always assume errata will be treated perfectly.
This is reproducible with the Zoo repo with the following steps:
1) Sync Zoo (https://jlsherrill.fedorapeople.org/fake-repos/needed-errata/)
2) Register a content host and install walrus-0.71
3) Delete all walrus packages from the repo
4) Create a content view with Zoo and publish
5) Switch the content host to use your new Zoo content view
6) See that the RHEA-2012:0055 is marked as installable, but you cannot install it.
So, I think the best way to fix the bug will be to update the installable errata query to cover the Zoo case here. We could consider filtering out these errata from the CVs instead, but that's more bug-prone and we need to be more careful about filtering out errata. Missing errata could mean missing security patches.
Updated by Ian Ballou over 2 years ago
I put this on 4.5.0. I know it probably won't make it, so let's put it on 4.5.1 when 4.5.0 is out.
Updated by Samir Jha over 2 years ago
- Target version changed from Katello 4.5.0 to Katello 4.5.1
- Triaged changed from No to Yes
Updated by Ian Ballou about 2 years ago
- Target version changed from Katello 4.5.1 to Katello 4.6.1
Updated by Ian Ballou about 2 years ago
- Target version changed from Katello 4.6.1 to Katello 4.8.0
This issue is much more complicated than I expected due to how we copy repositories round-robin when dependency solving isn't involved. The real fix for this issue would be to refactor content view copying to use the "multi-copy" actions that get used during dependency solving. Only then will we have the proper multi-repo knowledge to solve this issue.
For now, if anyone hits this rare problem when filtering packages out of content views in AppStream + BaseOS repos (CentOS, Alma, Rocky, etc.), you can workaround it by excluding the errata in question.
I'm changing the target to Katello 4.8 for now. I don't think we should backlog it, but I'm guessing the fix won't be safe to backport.
Updated by Ian Ballou almost 2 years ago
- Target version changed from Katello 4.8.0 to Katello 4.9.0
- Difficulty changed from medium to hard
Updated by Lucy Fu over 1 year ago
- Target version changed from Katello 4.9.0 to Katello 4.10.0
Updated by Chris Roberts about 1 year ago
- Target version changed from Katello 4.10.0 to Katello 4.11.0
Updated by Ian Ballou 11 months ago
- Target version deleted (
Katello 4.11.0)
Backlogging this since we haven't had time to it in a couple years.