Les Mikesell <lesmikesell@xxxxxxxxx> writes:
> No one needs to know anything about the many ip addresses these
> requests may originate from. All that needs to happen is that they
> are repeatable when going through proxies.
<sarcasm>Oh, is that all. Like all I need to do is solve faster than
light travel, and we're good to go?</sarcasm>
> If you feel that you have
> to rotate/randomize the mirrorlist if one exists
Yum doesn't do this and can't stop MirrorManager/whatever from doing
it (and MirrorManager does it for a _reason_, not just on a whim).
>, how about hashing
> the proxy name specified into an index for the starting attempt so
> every machine with the same proxy will make its first request to the
> same target? Or use a token passed on the command line for that
> purpose.
Again, you are assuming that "mirrorlists" is a static set of data
in the repo. ... this is _not true_.
It is absolutely fine for two machines on the same network, using the
same proxy, to get two completely different "mirrorlists" (or to have
some of the same data in a different order). Even with the move to
metalink data, we can't make a syncronized DB out of the data we
have. And I'm sure I've explained exactly the above to you before.
As I'm _sure_ you know, MirrorManager has options to allow the user
to pick a "best" mirror for IP ranges they own.
> If you would permit caching to work the way it is intended, distros
> probably wouldn't need all those mirrors anyway and other people
> wouldn't have had to invent a dozen different ways to work around what
> yum does when updating multiple machines.
Sure, scaling out from a single point of reference is very easy in
HTTP ... we/Fedora/CentOS/etc. are just too dumb to do it. As are all
of Akami's customers.
Feel free to enlighten us/Fedora/CentOS/etc.
--
James Antill -- james@xxxxxxx
_______________________________________________
Yum mailing list
Yum@xxxxxxxxxxxxxxxxx
http://lists.baseurl.org/mailman/listinfo/yum
