Hi, Am 13.04.2012 um 01:59 schrieb Rob Weir:
> On Thu, Apr 12, 2012 at 7:40 PM, Peter Pöml <pe...@poeml.de> 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 ;-) Peter
