Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
If a user configures retain_package_version=1 (or 2, or 3, or any number), while also using an "immediate" download policy, all packages are downloaded even though they will be immediately orphaned. This can use a significant amount more network bandwidth on a recurring basis if orphan content is cleaned up regularly and make syncs take longer compared to the alternative of not downloading those packages.
In one sense this is a bugfix, as it resolves unintentional behavior. But it can also be considered an enhancement, as it would allow users to download only a small portion of the package data and gain significant disk, network and time savings while still using an immediate download policy.
Version-Release number of selected component (if applicable):
6.10, 6.11 (won't be fixed in 6.10)
How reproducible:
Always
Steps to Reproduce:
1. Set up a sync of a large repository such as RHEL 8 or RHEL 7 using download policy "immediate" and "retain_package_versions=1"
2. Sync
3. Observe that 60+gb of packages are downloaded
Expected results:
Sync will complete very quickly, only needing to download ~6gb of packages.
Additional info:
* If orphan cleanup occurs then this process will repeat, multiplying the resource wastage
Steps to retest:
1. Go to settings and turn rhel download policy to "Immediate"
2. Enable RHEL8 and RHEL7 repos
3. Drill into the product -> <product> -> <repo> page
4. Change the mirroring policy to "additive" for both repos(this will open the "retain package versions" field
5. Edit the "Retain package versions" field to 1
6. Save repo and perform sync
Expected:
Syncing should complete relatively fast and the number of packages should be reduced significantly
Actual:
Syncing completed relative fast (about 10 minutes) and the number of packages is reduced. For rhel8_baseos, it was 1788 rpms and rhel7, it was 5499.
Verified on 6.12 snap 10 with python39-pulp-rpm-3.17.10-1.el8pc.noarch
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Important: Satellite 6.12 Release), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2022:8506