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. > 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
