9:24 a.m.
Jeff Spaleta <jspaleta@gmail.com>(a)redhat.com on 09/29/2004 05:01:18 PM
wrote:
On Wed, 29 Sep 2004 14:41:17 -0400 <fulko.hew(a)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.
11:31 a.m.
New subject: Automated Mirror Selection [Re: Worst experience with Up2Date ever.]
On Thu, 30 Sep 2004 10:24:08 -0400, fulko.hew(a)sita.aero
<fulko.hew(a)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
7142
days inactive
7142
days old
1 comments
2 participants
participants (2)
-
Fulko.Hew＠sita.aero -
Jef Spaleta