Mirror monitor for meta data repos

[Jeff Spaleta]

On 6/7/05, david <dfarning at sbcglobal.net> wrote:
> Good heavens man, I just working on this a few hours ago. So as they
> say, "The concrete ain't set up real firm yet."

Easy, I'm just making suggestions I'm not throwing stones. You did ask
for input.

> Every time a master timestamp is changed all mirrors are immediately
> reprobed to eliminate "the dreaded unknown state."

I have concerns about how immediate  'immediately' means in practise.
You will be probing some mirrors which are under heavy load or have
reached their client connection limit. You have to account for some
finite timeout and a mechanism to go back and re-attempt. Trust me..
first week of release you will run into overwhelmed mirrors because of
both the people grabbing isos as well as people trying to get 0-day,
1-day, 5-day updates.  And again when something like an important
security update comes out some mirrors can get stressed again. How
long is it going to take to successfully connect and probe 100 mirrors
on release day or the day after release. There will most likely be
some updates with in the first 24 hours.  And some mirrors will reach
their connection limit and you will have ot make repeated attempts to
probe. You can't call these mirrors broken.  Can you accurately
distinguish broken mirrors from overwhelmed mirrors in the first week
of release?

> How would you feel if I stated the time since the last probe so user are
> aware of that fact.

Time since last probe.. as well as putting that mirror in the
unverified state... would be good.  I want to avoid situations where
this summary generates erroneous mail to the mirror-admin.  If this
script can't probe because of too many clients for a 10 or even 24
hours, the mirror admin doesn't need to be contacted about that.
Especially on release week... it could simply mean the mirror really
is being heavily used and your script can't get a connection.

-jef