Am 04/06/2012 11:46 PM, schrieb Rob Weir:
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.
We don't need to discuss about Bouncer. I think nobody will back to this
system. If, then we have to change back to the old file name schema
which was a bit messy.
But I see some advantages when we keep MirrorBrain:
- it would be a second alternative besides SourceForge
- it has a location-driven redirector
- it's a stabil system
- it's used already for other software
- I haven't seen a significant outage over the last - hm I don't know -
2 years.
- it is already working very well for the legacy OOo release files
- there is no need to host an own server at Apache, we can use the
external service from Peter Poeml
All of course is IMHO.
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.
I think this would increase the current logic to infinity. And it is
already split up in parts.
Instead I prefer to split the 2 parts from each other: legacy OOo and
new AOO.
Otherwise we have to put:
- different mirror server
- different versions
- different set of supported platforms
- different set of supported languages
- different file name schemas
under a single hat. Puh, what a task.
So, for the legacy part we can use the
"http://www.openoffice.org/download/other.html"; webpage (with a new
name) for the builds. A single-green-download-button is than no longer
needed.
And for the new builds we change the current logic to be more
Apache-compatible.
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.
Yes, we need a possibility to disable the redirection to a specific host
in case of an outage or similar. E.g., set a variable simply to 0%.
Again, if anyone has cycles to help with this script, please speak up.
I'm not a Guru of JavaScript and CGI and have not as much time as others
here on the list. But I can try to find something.
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.
Marcus
