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 16:39:55 GMT
Am 04/06/2012 06:27 PM, schrieb Rob Weir:
> On Fri, Apr 6, 2012 at 12:11 PM, Marcus (OOo)<>  wrote:
>> Am 04/06/2012 04:34 PM, schrieb Rob Weir:
>>> Please note:
>>> 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
>> ( 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.


View raw message