incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Pöml <>
Subject Re: Ditching our mirror system for an inferior solution? (was: Re: About Testing the SourceForce Mirror of AOO 3.4)
Date Wed, 18 Apr 2012 21:19:15 GMT

Am 13.04.2012 um 01:59 schrieb Rob Weir:

> On Thu, Apr 12, 2012 at 7:40 PM, Peter Pöml <> wrote:
>> Hi,
>> Am 03.04.2012 um 18:17 schrieb Roberto Galoppini:
>>> We at SourceForge have worked the last ten days to line-up dedicated
>>> infrastructure (including CDN services) to support the upcoming AOO
>>> download serving test.
>> I can hardly believe reading this! What's going on? We have an existing (and well
working) mirror network, that handles any required load just fine. It's proven and time-tested.
It has survived all releases with ease. By all calculation, and by practical experience, the
combined upload capacity of the mirrors is sufficient to satisfy the peak download demand
as well as the sustained demand. By the way, the "peak download demand" doesn't really differ
a lot from the day-to-day download demand, contrary to public belief. The mirrors are numerous
and spread around the world, and the chance of a client being sent to a close and fast mirror
is good - better than with a handful of mirrors as is the case with the Sourceforge mirror
network. Sourceforge specializes in something different - providing a myriad of small files
by a set of specialized mirrors. "Normal", plain simple mirrors can't take part in this network
as far as I can tell. Even though the network was considerably extended a few years ago, from
10 (under 10?) to >20 mirrors, this is still a small number of mirrors. (Even though these
are power-mirrors, but those are part of our existing mirror network just as well.)
> Hi Peter,
> I don't think anyone is proposing to toss out MirrorBrain.  The

Then I must have misunderstood a substantial part of the communication then, or I missed relevant
parts, because so far it sounded to me as if MirrorBrain is not going to be supported, or
at most only for "legacy downloads".

So: sorry if I missed something (or maybe something wasn't communicated in public but on some
private list) -- but I'm glad to hear that you don't rule out continuing using the existing
mirror system anymore.

> most-recent conversations have been about how we can make our download
> page farm out to all three: Apache, MirrorBrain and SourceForge.  The
> idea would be that we would have sufficient capacity even with the
> failure of any one network.

I strongly advise against deploying three mirror systems at the same time. I see several severe
disadvantages with it:

- If a user reports a problem, you don't know through which system the user was sent. It's
complicated enough with a single system to find that out what's wrong
- it'll probably be impossible to debug issues, since you either don't know which system is
to be debugged, or can't reach anybody from the foreign system or it is too much effort (or
practically takes too long) to pass info forth and back. 
- it's a triple effort to maintain three mirror systems
- QoS (quality of service) doesn't come from uninterrupted services, but from good service
in the first place
- having three different systems will mean three different levels of quality of service

For fallback reasons, it might be a logical thought to have several systems. But I'd rather
get one thing right :)

> Another consideration is this:  We know that the administrative site
> of the Apache mirror network is reliably staffed.  I believe that
> SourceForge is reliably staffed.  But what about our MirrorBrain
> usage?  How many people on the AOO project know all the details about
> publishing to the network?  If we had to do a release -- say a
> security patch -- and you were on vacation, do we have the ability to
> do it?

There's rsync and ssh, and people willing and able to collaborate. There's really no reason
why a release should be doable only by one person. Things like these are usually done in collaboration,
anyway. I don't see how this could depend on one person. The actual act of releasing usually
boils down to a few one-liners or simple shell scripts to be run in order, which are easy
to share, and easy to learn. (By the way, for large software packages, it is very useful to
have a staging area to be able to fill mirrors before actually publishing files. Something
that this project should have, and which the Apache mirror system probably doesn't provide.)

I wasn't directly involved in any release of OOo, for that matter :-)

Since you ask about staffing: Just not to be misunderstood, MirrorBrain is not a "service".
It is just a piece of open source software. The fact that I use it myself to provide download
services to OOo doesn't change this, and anyone, including ASF infra, is free to use MirrorBrain.
My recommendation is that ASF infra upgrades from closer.cgi to MirrorBrain, because then
they can integrate the existing OOo/AOo mirrors into Apache mirroring easily. With closer.cgi
alone, it will hardly work. Then you'll have as much staff as you want ;-)


View raw message