Jeff Spaleta jspaleta@gmail.com@redhat.com on 09/29/2004 05:01:18 PM wrote:
On Wed, 29 Sep 2004 14:41:17 -0400 fulko.hew@sita.aero wrote:
The list of mirrors should/could at the very least be a package that we can download to get the 'latest set' of behaving mirrors.
you create a server that holds a 'latest set' of behaving mirrors...and keep that server running for people to use...and im sure people will use it.
It seems that the main server already has this list (because its not a local config (that I can find)).
Can the master server check the mirrors to see if (all of) their
transfers
have been completed, and only then re-add that mirror to the list of candidates?
Why does the master server have to do this. If you think this will work...you create a seperate server, that tries to detect which mirrors are synced. Read my rules of engagement in this discussion.
Sorry, I just went back to find them, and read them
If you think you can get this to work...set it up on a community site and host a list of 'good' mirrors. Show it works independant of the main site.
After trying to figure out why the 'package size' info reported by up2date is now broken, I don't have the time to figure out how its supposed to work. Since I haven't found any design notes or documentation on the communication process, or message flow used by up2date et.al., I gave up in frustration when faced with the massive amounts of reverse engineering that would be required.
In this case I was complaining about a blatently 'dead' site, and to the best of my knowledge, has never worked since it was added to the master list. I know its manual, but the list of hosts that the master site maintains (and distributes) could easily, manually, be updated to remove this entry. One person, one time, 15 seconds, and the community would have one less thing to grip about. Give me access to that site, and I'll do it!
Sure, it would be nicer if the mirror could just 'tell' the master,
rather
than have the master poll...
Read my rules of engagement for this discussion. Sure it would be nicer...but its not reality...its not going to happen..you arent going to be able to demand this of mirrors and still expect as many mirror admins with high bandwidth to volunteer to be a part of the official mirror list.
The reality of networking is that: a mirror isn't a mirror, unless its accessible, and it actually _is_ a mirror... volunteer or not. Wrong information is worse than no information.
PITA scripts should be a prerequisite to becomming a mirror, or at the
very
least to be a mirror that gets put into the mirror list.
shoulda,woulda,coulda... you clearly didn't read my ground rules for participating in this discussion. And as promised I'm now going to point and laugh at you.
<point and laugh mode> HaHa look at the funny person HeHe </point and laugh mode>
You can laugh all you want, but that makes you part of the problem and not part of the solution. I'm sorry if you are not open to constructive criticism.
... snip ...
Face facts, you up the maintainership burden to be a fedora official mirror and you will drop the number of mirrors listed in the official list, since it really makes no difference to most mirror admins if they are on the official fedora list or not.
See my statement above... If your not accessible, or not mirroring, then you are NOT a mirror, and shouldn't be on the official (communicated) list.
I think thats too complicated. Something that notifies when the rsync
is
done is better.
Flying cars are better than cars with wheels....so what...you aren't going to mandate that we all start using flying cars. Just like you are not going to mandate to the mirrors that volunteer their bandwidth to run addition services to make it easier for user to know when the sync is done...it just isnt going to happen.
Compared to the bandwidth used to actually mirror the sites, and to supply the mirror to the world, the notification process is a trial amount of bandwidth or effort.
There are political and technical realities that must be considered and you aren't considering them. Let me take a quick moment to point and laugh at you again. HaHa...HeHe...
Your laugh indicates your immaturity, and your reluctance to solve the problem. Your 'rules of engagement' provide a number of restrictions, but without justification. Given them, it is impossible to provide a usable environment.
I contend that your rules are un-realistic.
If the mirrors are using rsync, then there has to be a cron job (or equivalent) set up on the mirror to perform the sync. The mirror administrator has already committed to setting that up... and maintaining it. That cron job could easily be extended to perform its rsync in two stages, to address the headers versus RPMs issue, and to add an rsync that pushes back a nodeName, date stamp file back to the master site. Anyone, (and I'll volunteer, if the appropriate access rights and design information are given) can write the simple script that checks these files and builds the master list from it.
On Thu, 30 Sep 2004 10:24:08 -0400, fulko.hew@sita.aero fulko.hew@sita.aero wrote:
In this case I was complaining about a blatently 'dead' site, and to the best of my knowledge, has never worked since it was added to the master list. I know its manual, but the list of hosts that the master site maintains (and distributes) could easily, manually, be updated to remove this entry. One person, one time, 15 seconds, and the community would have one less thing to grip about. Give me access to that site, and I'll do it!
You want a dead site removed from the default mirror list? Is that all you want? Have you filed a bug in bugzilla about it? Because the only way to get any bugs fixed..is to get bugs filed in bugzilla. Getting a known dead mirror dropped from a list.. takes 15 seconds for you as a user to file as a bug report to inform the up2date package maintainer about. But you talked about much more than just getting known dead sites removed from statically created manually maintained lists.
You can laugh all you want, but that makes you part of the problem and not part of the solution. I'm sorry if you are not open to constructive criticism.
This isn't constructive. But if you want to be constructive I will give you some homework. You go to the official mirror list, contact each mirror list admin on the list currently. Ask them politely ask if they would be willing to implement new PITA script logic that is fedora specific to communicate back to a centralized server and see how many mirror admins are willing to do it. To a lot of mirror admins, fedora is just one of many ftp/rsync trees that they mirror, and implementing special script logic just for fedora is not something they want to do just to be listed on a list. The hard issue is not technical..there are technical solutions... its not hard to dream one up... its not hard to implement a proof of concept. The hard issue is political. You have to get mirror admins to agree to use fedora's special PITA script logic if you implement it. Please, by all means, start communicating with the mirror admins and get them to agree to implement special script logic.
But as I have suggested... the best way forward..before we start DEMANDING mirrors to use new script logic..is for someone in the community... to implement a proof of concept service and start getting mirror admins who are willing to test/use the service to be apart of the testing. I'm quite sure if you started screwing around with a service that attempted to provide a dynamic mirrorlist to use that could accurately describe which mirrors were in sync with the master mirror, you would find one or two mirror admins who would be willing to help and you certaintly would find community willing to use it. But any discussion that starts with demanding mirror admins to do anything extra to be listed... is a non-starter. The hard part is political, and you aren't going to win political points by demanding new policies on the mirror admins. Are you willing to drop 80% of the mirror list by demanding specialized script logic? There is no point i demand a technical solution that mirror admins aren't going to use.
Compared to the bandwidth used to actually mirror the sites, and to supply the mirror to the world, the notification process is a trial amount of bandwidth or effort.
Fine.. build a server and a service and the mirror side scripts and offer it for community to test. Demanding red hat build this and demanding mirror admins to use this doesn't get us anywhere faster. So, i await your email to fedora-list advertising your new dynamic mirror list service for up2date. I can't wait to test it.
-jef