Publishing a CV with depsolve=true and filter "exclude errata issued after date" randomly forgets to apply the filter
Description of problem:
Under unknown circumstances, and randomly occurring, CV filter "exclude errata issued after date .." is ignored during CV publish, when dependency solving is enabled.
Particular reproducer (sporadic occurrence, though):
Having a CV with:
- RHEL8 BaseOS
- RHEL8 AppStream
- RHEL8 Supplementary
(probably the more repos, the bigger chance to reproduce is)
Having dependency solving enabled (this is crucial)
Then having two exclude filters:
- Exclude errata issued after 2021-10-01 (applied on all repos)
- Exclude puppet and puppet-agent packages (of all versions, from all repos)
- this might be irrelevant filter
and publishing the CV, it sporadically leaves RHEL8.5 errata with some content in it. E.g.:
RHBA-2021:4431 (issued on 2021-11-05)
are in, but e.g. device-mapper-event-1.02.177-10.el8.x86_64 (that is dependant on the above ones) is removed (which sounds correct).
Thus, CV content - despite dependency solving set - has inconsistent content with broken dependencies among packages.
The cause is that pulp repo for CV version is published (DistributorPublish step) before the unwanted content is unassociated (PurgeEmptyContent). And the "versioned" repo is then used for the "CV in Library" repo during that repo publish.
Anyway, the above sequence of steps happens every time, but we can reproduce it sporadically only - there must be some other factor contributing to it (or just unlucky race condition?)
Version-Release number of selected component (if applicable):
(newer Satellites probably affected the same)
Steps to Reproduce:
See above steps
CV content with broken dependencies and unwanted packages
CV content with "dependency closure" and without unwanted packages
- for the "versioned BaseOS repo", the errata RHBA-2021:4431 is in published metadata, BUT NOT in mongo (repo_content_units)
- the device-mapper -177 version is in published metadata, not sure if in mongo (repo_content_units) - PROBABLY it is there
- workaround in force_full publish of "versioned" repo and then force_full publish of "Library" repo removes the errata from the repos metadata, BUT keeps package in (hence mongo probably keeps the association)
- I think ordering of dynflow steps:
34: Actions::Pulp::Repository::DistributorPublish (success) [ 390.51s / 7.15s ]
39: Actions::Katello::Repository::PurgeEmptyContent (success) [ 1.53s / 0.49s ]
is wrong. We must call the Publish (of CV-versioned repo) after PurgeEmptyContent
- BUT just the above change will probably not purge away the packages..? (as the workaround idea above failed)
#3 Updated by Ian Ballou 4 months ago
- Target version changed from 3.18-no-release-planned to Katello Recycle Bin
- Status changed from Ready For Testing to Closed
Closing this out because the unwanted packages are resulting from the dependency solver doing its job.
The issue can be partially mitigated by having BaseOS get copied before AppStream, but that hardcoding is bad design because there can still be repoclosure issues from factors not controlled by Katello.
The documentation will be updated to make dep solving's role more clear.