Mirror monitor for meta data repos

[david]

Jeff Spaleta wrote:

>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.
>
>  
>
I should have put a little simley face  after the  above comment;)  You 
best not be gettin' stones in my wet concrete;)

>>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?
>  
>
You are taking this farther than I intended.  This version is just a 
quick visual tool to see the general status of the mirror system.

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.

Thus, allowing security release to be pushed rather than pulled through 
the system.

But, that will require buyin from the  build system as well as the mirrors.

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.
3.  Create a single point of truth from which uptodate regional mirror 
lists can be automatically generated for use with yum.
 
When the above three things start to fall into place.  I'll start work 
on the push system.

>  
>
>>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.
>  
>
Good point, I will replace the term "mirror failure" with "probe failure."

Note to self.  "How and when to push information to mirrors?"

Thanks for the input
-dtf