Automated Mirror Selection [Re: Worst experience with Up2Date ever.]

Fulko.Hew at sita.aero Fulko.Hew at sita.aero
Thu Sep 30 14:24:08 UTC 2004



Jeff Spaleta <jspaleta at gmail.com>@redhat.com on 09/29/2004 05:01:18 PM
wrote:


> On Wed, 29 Sep 2004 14:41:17 -0400 <fulko.hew at 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.







More information about the test mailing list