Automated Mirror Selection [Re: Worst experience with Up2Date ever.]

[Jeff Spaleta]

On Wed, 29 Sep 2004 09:56:27 -0500, Chris Adams <cmadams at hiwaay.net> wrote:
> How is this mirror list created?  

I honestly don't know how the default mirror lists are created. I
suspect the developer just created them by hand using some personal
experience associate with  which mirrors were reliable.

> How does up2date (or yum) handle a mirror not having what is being
> looked for?

I think they both handle lack of a tree somewhat gracefully and failover.
I think neither handle a tree being out of sync with the master very well.
 
So if a mirror doesn't have a specific tree i think they failover to
the next mirror in the list.
What "next" means i think is different between yum and up2date. yum im
pretty sure marches down the list. up2date might "pick" another mirror
from the list somehow,

>  For example, mirror.hiwaay.net is in the list, but I don't
> mirror all the rawhide architectures (just i386 and x86_64).  Does
> up2date recognize a 404 and try another mirror?  Is this action
> remembered?

I don't think there is any cleverness about remembering if mirrors
have gone sour and removing them locally from the client. You have to
be careful with this sort of logic. A specific mirror could fail for a
temporary reason, so trying to be clever and remember that it failed
could prevent you from ever using that mirror again just because it
had a short period downtime event once.

> One problem with syncing rawhide to mirrors is that the daily build and
> push of rawhide to the master servers takes a different amount of time
> (and so finishes at a different time) each day.  Some days, my sync
> finishes before the push is complete, so until my mirror syncs again
> (once a day), it will be effectively fubared. 

Okay this sort of problem could maybe be preventable with small
changes on the master server, if there was a way to implement a
start/stop file on the master servers that mirrors could check to see
if a rawhide push was still in process and delay starting a sync
attempt until the rawhide push on the master server was done.  But
even if the small technical change on the master server was made, all
the mirrors would have to write/use scripts to take advantage of the
change and there is no way you can enforce mirror admins to do that
across the board. Its the politics of individual mirror admins. So
while you might use this to make your mirror more reliable... i don't
think you can count on all admins to do it.

> One thing I've considered
> doing is to change my mirroring scripts to watch for actual file syncs
> and loop (with a small delay) until the sync runs without changing any
> files.  That would help, but there's still a period where my mirror of
> the tree is not in sync.  I guess if I synced the header.info and
> repodata files last and then deleted, I should always have a consistent
> tree, but scripting that will be somewhat of a PITA.

The heart of the problem... anything that is going to make mirrors
significantly more reliable is going to end up being a solution that
puts a heavy burden on the mirror admins.
PITA scripts or extra services that communicate back or whatever. The
maximum reliability in terms of how out of sync an invidiual mirror
can get basically comes down to how much care and feeding individual
mirror maintainers are willing to do. So even if you get scripts in
place on your mirror that work to keep your mirror synced with the
master mirror, its not clear to me that you can get equal effort from
the other mirrors who are volunteering their bandwidth to host the
packages.

And if we can't get all the mirrors to be reliable, then the only
other way to do it, is to have some scheme that dynamically checks for
out of synced mirrors and ranks the reliability of mirrors so that
over time, clients who are connecting to mirrors get a preferred set
and never set a set that is known to be out of sync.  But, i have not
seen a scheme that doesn't require an admin to run extra services or
scripts, that is garunteed to catch a mirror being out of sync and
prevent a client computer from contacting a mirror that is out of
sync.

-jef