Re: a new MirrorManager-related tool for stripping old metadata and pushing critical updates in a defined time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Fedora Development]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux