On Fri, Apr 6, 2012 at 4:46 PM, Marcus (OOo) <[email protected]> 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
