Proposed upcoming mirror changes

justin

1

We’d like to announce some proposed changes to how we mirror and
distribute our various products and builds. Our current mirror size is
approaching 500gb – much too large and costly to ask our mirrors to
support. Thus, we have come up with a new and improved mirror strategy
to help alleviate the space and bandwidth issues associated with
supporting such a large mirror site while retaining our ability to
distribute our software in a quick and efficient manner.

We will take comments until 6/8/06 with implementation scheduled for
6/9/06 assuming no major objections. Please take the time to read
through the changes and let us know if you have any concerns with the
proposed plan. Note – there should be no end-user effecting changes.
All of these modifications will be transparent to the user.


* There will be 2 rsync modules/data repositories:
o Releases – this will be all releases which have been
released with the last year. This includes rc’s, beta’s and alpha’s. All
bouncer files will be contained within this module.
o FTP – this will contain all of the releases module plus all
old releases (beta’s, alpha’s and rc’s) and any nightly builds.
ftp.mozilla.org and archive.mozilla.org will go to this data set.

* Anyone who would like to mirror Releases will *have* to mirror
from releases-rsync.mozilla.org (TDS and OSL – as most should be doing
now). We haven’t enforced this and there are a few people who are still
mirroring off surf (i.e. stage). This has a few bad ramifications around
virus scanning, bandwidth, etc – we’ll just start enforcing that people
use the correct rsync mirrors.

* Master mirrors (OSL and TDS) and standard mirrors won’t rsync the
FTP module, instead only the releases module. This will mean that all
ftp.mozilla.org traffic will come directly to Mozilla. Our main mirrors
do not want to keep this much data online and we can easily handle
traffic. Any high-traffic builds/releases should be in the releases module.

We are in discussions with our major mirror sites to make sure the
changes are implemented with minimal downstream impact. Again, please
let me know if you have any questions/concerns/issues with the new setup.

One response

  1. David B. Haun wrote on :

    Disable the Mozilla 1.7, Avairy 1.0, and Avairy 1.0.1 tinderboxen first to reduce number of builds.