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