repo-mirrorlist quality control?
kevin at scrye.com
Wed Feb 25 20:45:20 UTC 2015
On Wed, 25 Feb 2015 18:58:54 +0100
Ralf Corsepius <rc040203 at freenet.de> wrote:
> I sense a misunderstanding. With "pushing" I was referring to
> "uploading/publishing" a package to the repository on the master.
> The mirrors were polling ad lib, at intervals at their preference.
Ah right. Then yes, we do the same thing. We 'push' new content to the
master mirrors, mirrormanager sees it there and updates, the other
mirrors pull from it.
> I.e. when updating the master repository on the server, we emptied
> our mirrorlists, and let the _master_ poll repomd.xmls from the
> _mirrors_. When it found a mirror's "repomd.xml" was in sync, the
> mirrors was re-add to our mirrorlists on the server.
Right, so this would be a 'add when updated' rather than 'remove if
outdated' model. I'm not sure it would work too well for us because we
have so many repomd's to consider and it would take a while to crawl
all mirrors for those to re-add. But it's a thought. We do keep the
previous one in the metalink too, so that might help with overlaps (ie,
add if either previous or current)
I guess there's 56 repomd.xml's on the active fedora releases, plus
another 42 for epel.
> As I am heavily using mock, I am fairly often seeing this issue with
> mock. With mock w/ rawhide I am even observing hard build-breakdowns
> (Seems to me as if something in f21's mock was changed to not let it
> use mirrors)
huh. Mock did change in rawhide to use dnf... not sure if thats
> > The next time this happens can you file a ticket with the output?
> I can try - However, during some periods in recent weeks, these
> incidents were so frequent, I'd not to anything else but filing
> tickets ;)
Indeed. well, let us know if you can file one...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the devel