On Mon, Feb 08, 2016 at 07:43:14AM -0500, Kamil Paral wrote: > > On Fri, Jan 08, 2016 at 02:40:52PM -0500, Patrick Uiterwijk wrote: > > > > 3. The tool will go through all metalinks for f23-updates (all primary > > > > architectures), and drop each <mm0:alternate> section which has > > > > <mm0:timestamp> older than the provided date (let's say midnight UTC). > > > > > > Please note that there are no metalink files: these files are generated on > > > the fly from a cache > > > by the mirrorlist servers. > > > I have a patch for this that I'll submit upstream to add the feature > > > itself, and will discuss > > > with releng how they want to fire this off. > > > > The new script is now available on mm-backend01: mm2_emergency-expire-repo > > > > I think I have seen that Patrick also created a playbook to let the > > script run in the correct environment and configuration. > > > > We have successfully tested the script in the staging environment and > > after it runs only the newest repomd.xml file is listed in the metalink. > > > > As far as I understand MirrorManager this script only changes the number > > of alternate repomd.xml files in the metalink. The number of mirrors > > returned does not change. Depending on the last run of the master mirror > > crawler (umdl), the state of the crawler checking the mirrors and the > > mirrors which are running report_mirror this may lead to situation where > > mirrors are offered to clients which might not yet have the newest > > files. > > In other words, some of those repos included in the metalink might not correspond to the included repomd.xml hash, right? Correct. > Is that a problem? I believe DNF should just skip those repos and find the first one which matches the provided metadata hash. It shouldn't be a problem. It is a situation which can happen anytime. Just wanted to mention it once more. Adrian
Attachment:
pgpiM0rjUTFm5.pgp
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx