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.