Jeff Spaleta wrote:
On 6/7/05, david <dfarning@xxxxxxxxxxxxx> 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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-devel-list
