Am 04/06/2012 06:27 PM, schrieb Rob Weir:
> On Fri, Apr 6, 2012 at 12:11 PM, Marcus (OOo)<marcus.mail@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
|