Mirror monitor for meta data repos

[Jeff Spaleta]

On 6/7/05, david <dfarning at sbcglobal.net> wrote:
> You are right about the above short comings, in future versions I would
> like createrepo to push a message to m3d  to say that  something has
> been updated.  Then createrepo could call a tool that walks down the
> mirror list letting  child tiers know that they need to sync.  The
> children would then push a message to m3d that they are done syncing.

While a noble idea... i'm not sure a lot of the official mirrors are
going to be thrilled about running an additional service on their
mirrors to listen to that push.   I think you need to gauge how many
current mirrors are interested in running an additional service to
before you think about that push system too much. It's technically
feasible.. but I'm just not sure if its going to be popular with the
current mirror admins, if it means another service to setup and
babysit. If only 5% of the mirrors are willing to run an additional
service to handle that centralized push, its sort of a non-starter. 
Maybe some mirror admins lurking on this list can weight in as to the
political feasibility for adoption of any push system.

Unless something has changed, I don't think the mirrors are organized
into a several tier system. And if there is a tiered system in place
right now for mirrors, the system you want to create could end up
driving users to the higher tier servers that get the updates first,
defeating the point of tiering.

> For now, I want focus on a tool that
> 1.  Creates visability of the mirror system as a whole.
> 2.  Allow the mirror master ( in this usage the master is the guy who
> keeps the mirror list up to date) to quickly inspect the overall state
> of the mirrors.

Hmm.. if you are talking about the centralized mirrorlists at
fedora.redhat.com... I'm not sure who the right person to talk to is.
Let's see if I can taunt them into expressing an opinion as to your
approach as a follow up to this thread.

> 3.  Create a single point of truth from which uptodate regional mirror
> lists can be automatically generated for use with yum.

Truth is subjective. And if you aren't careful you can end up having
this tool generate very small mirrorlists which point people to just a
few quickly updated mirrors and end up driving too much traffic to the
first mirrors who happen to catch an update.. causing client
connection failures when those quickly updated mirrors max their
connected clients.   How often do most official mirrors attempt to
rsync with the master now? If they only do it once an hour you
shouldn't probe more often than about 2 hours realistically or else
you just might happen to probe just after the master mirror syncs
before any mirror's own rsync script has fired.

> Good point, I will replace the term "mirror failure" with "probe failure."
> 

There can be mirror failures... but i think you have to wait for a
mirror to go missing for a few days straight before you can
distinguish in the case of too many connection errors.  Can your
script tell the difference between error states handed back from the
server?  Don't you get different messages back from the server if the
server is full instead of down? Or when the directory is not there or
you dont have permissions to access the directory?

I'm still interested to watch how long it takes for you to do a full
run on a heavy load day with updates like the day after a release. Hey
look there is one right around the corner. Hopefully you'll do a few
timed runs of that 200+ mirror update check  in that 48 period after
release and get a better feel for how bad it can get and show me my
concerns are completely unjustified.

-jef