incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <>
Subject Re: Live testing of SF download mirrors
Date Fri, 06 Apr 2012 22:52:03 GMT
Am 04/06/2012 11:46 PM, schrieb Rob Weir:
> On Fri, Apr 6, 2012 at 4:46 PM, Marcus (OOo)<>  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:
> (The closer.cgi will determine the closest mirror).
> And the SF mirrors will look like:
> 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 
"" webpage (with a new 
name) for the builds. A single-green-download-button is than no longer 

And for the new builds we change the current logic to be more 

> 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.


View raw message