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.
1. Proposed title of this feature request
Adopt same repo sync timestamp on load-balanced Capsules as found on Satellite, to avoid yum cache issues
2. Who is the customer behind the request?
(Will be provided in a private comment next.)
3. What is the nature and description of the request?
While syncing repos from Satellite, load-balanced Capsules will calculate their own timestamps and set those in the repo metadata for the same repo. Yum clients connecting through the load-balancer will usually connect to a different capsule every time.
In case the contacted capsule offers an _older_ timestamp, yum warns the user that the server's timestamp is older than the local cache's timestamp.
When the contacted capsule offers a _newer_ timestamp by any amount (e.g. a microsecond) the yum client will refresh its metadata believing the capsule's repo to be newer than what's cached locally.
By having capsules' Pulp imitate the same timestamp as is offered by Satellite we could prevent this issue altogether.
4. Why does the customer need this?
Yum clients to load-balanced capsules are very often either (1) complaining at servers offering older metadata than the locally cached metadata (this is displayed by yum as an actual WARNING), or (2) needlessly downloading essentially the same repo metadata as they have locally because timestamps differ.
5. How would the customer like to achieve this?
On any Capsule sync, Satellite repo metadata (optionally, only timestamp info) would be copied over to and adopted by Capsules for those same repositories.
6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
Deploy load-balanced capsules, sync repos from Satellite to capsules, have yum clients connect to the load-balanced capsules to e.g. download metadata, wait a few minutes, have yum clients connect again. Check for needless yum cache refreshes or yum warnings about server metadata age.
7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
None that I could find.
8. Does the customer have any specific timeline dependencies and which release would they like to target?
No specific timeline but as soon as possible.
10. List any affected packages or components.
pulp-server
pulp-rpm-plugins
11. Would the customer be able to assist in testing this functionality if implemented?
No.
Comment 7Tanya Tereshchenko
2020-05-01 13:20:32 UTC
Keeping here as a future Pulp 3 feature.
WONTFIX in Pulp 2.
Comment 8Tanya Tereshchenko
2020-05-01 13:24:26 UTC