Am 04/06/2012 06:27 PM, schrieb Rob Weir:
On Fri, Apr 6, 2012 at 12:11 PM, Marcus (OOo)<marcus.m...@wtnet.de> wrote:
Am 04/06/2012 04:34 PM, schrieb Rob Weir:
Please note: https://issues.apache.org/ooo/show_bug.cgi?id=119194
I'm about to apply this patch. It will cause download requests to go
to the SourceForge mirrors instead of MirrorBrain. We want to confirm
that things are set up properly on the SF side, before we get the
deluge of downloads for AOO 3.4.
So please respond to this post with any oddities you see or hear about
with users downloading OOo 3.3 releases over the next few days.
Please tell me that you have tested the patch and are sure it's working
without problems. ;-)
Yes, that is why we have staging and production servers.
Otherwise I'm pretty sure something was not changed and it will lead to a
broken download service.
In any way, I recommend to setup a test phase in the test area
(http://www.openoffice.org/download/test/). Here we can do some try& error
games until it's working, without any interference of the production area.
OK, back to the patch:
"sf_download_main.patch":
This shouldn't be necessary as the host for the download link should also
come from a varialbe and not from hard-coded links.
It seems this wasn't changed until now. I'll do this, then the patch is not
needed.
"sf_download_isos.patch":
The distribution of the ISO files wasn't integrated into the download
service; except that the files were hosted by a server with MirrorBrain.
BTW:
Have we already discussed about these ISO files? Do we want to continue
this? If not, IMHO no need to migrate a dead service.
"sf_download_main.patch":
This is the heart of the download logic. Up to now only MirrorBrain was
used. In former times also Bouncer (from OSUOSL) but there were many changes
to make the migration from Bouncer to MirrorBrain successful. So, I don't
know yet if the changes in the patch are complete to offer another
alternative or if there is something more to change.
I would not treat the patches as the final UI or final logic that we
will use for 3.4. It is just a way to test the SF mirror under some
load. We can revert these patches once the test is over, or move to
something else.
If you want to test with load, then you won't get it in the staging area
but only in the production area. ;-)
So, yes we have a staging area but this won't help here.
For example, we might have logic that sends 75% of the traffic to SF
mirrors and 25% to Apache mirrors. We could adjust that with a
parameter in the script and tune it based on capacity.
I'm sure it's possible but as I wrote in a previous mail, the service is
currently working with only one mirror URL at the same time. So, we have
to change this first before we can balance the load.
Marcus
