incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Live testing of SF download mirrors
Date Fri, 06 Apr 2012 21:46:51 GMT
On Fri, Apr 6, 2012 at 4:46 PM, Marcus (OOo) <marcus.mail@wtnet.de> wrote:
<snip>

>
> I've just changed the used mirror host (see my other mail). In order to get
> the linked assembled together the version (e.g., "3.3.0") and used mirror is
> needed - plus a schema but since Bouncer is history it's no longer really
> needed.
>
> So, when "sourceforge" is not set as initial mirror host but "mirrorbrain"
> then the logic goes the MirrorBrain way.
>

What we really need, if you have cycles to look at it, is a script
that will randomly pick between the Apache mirrors and the SF mirrors.
 All this back and forth over MirrorBrain and OSUOSL/Bouncer is not
worth the effort.  Both are going away.

The Apache URL's will be under:

http://www.apache.org/dyn/closer.cgi/incubator/ooo/3.4/XXXX

(The closer.cgi will determine the closest mirror).

And the SF mirrors will look like:

http://sourceforge.net/projects/openofficeorg.mirror/files/3.4/XXX/download

I don't believe that we are planning on relying on OSUOSL for
downloads, nor MirrorBrain.  But I'd be open to a discussion if anyone
wishes to keep MirrorBrain active as well.

I think what we want is two script entry points for triggering a
download, one for legacy (OOo 3.3 and before) releases. These would
only be handled by SF and MirrorBrain.  And another for Apache
releases, where the Apache mirrors and SF would be used.

As we've discussed previously, it would be ideal if each script had a
tunable parameter that would determine how much traffic (%-wise) went
to each system.

For example logic like if (rand() <0.25) doApache() else
doSourceForge() would send 75% of the download requests to
SourceForge.  I think it is critical that we can easily adjust this
parameter.

Again, if anyone has cycles to help with this script, please speak up.
 This was not the intent of the current test. Right now we're just
looking at load and interface, not looking at the routing logic.  But
we will need to deal with the routing logic very soon, and certainly
before 3.4 is released.

-Rob

Mime
View raw message