incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [UPDATE SERVICE] dynamic approach [was: Re: [UPDATE SERVICE] activation of update service for OOo 3.1 and OOo 3.1.1]
Date Tue, 14 Aug 2012 19:31:36 GMT
On Tue, Aug 14, 2012 at 3:25 PM, Dave Fisher <dave2wave@comcast.net> wrote:
>
> On Aug 14, 2012, at 12:09 PM, Oliver-Rainer Wittmann wrote:
>
>> Hi,
>>
>> Am 14.08.2012 um 20:52 schrieb Dave Fisher <dave2wave@comcast.net>:
>>
>>>
>>> On Aug 14, 2012, at 11:43 AM, Rob Weir wrote:
>>>
>>>> On Tue, Aug 14, 2012 at 2:24 PM, Dave Fisher <dave2wave@comcast.net>
wrote:
>>>>>
>>>>> On Aug 5, 2012, at 11:13 AM, Andrea Pescetti wrote:
>>>>>
>>>>>> On 03/08/2012 Rob Weir wrote:
>>>>>>> On Fri, Aug 3, 2012 at 6:13 AM, Oliver-Rainer Wittmann
>>>>>>> wrote:
>>>>>>>> I am planning to give a talk on ApacheCon EU about
>>>>>>>> the update function in AOO and the Update Service. In this
talk I will give
>>>>>>>> a deep insight in its purpose and functionality which should
be enough input
>>>>>>>> for a corresponding volunteer to create a "real" web service
for our Update
>>>>>>>> Service. ...
>>>>>>> The question is:  how dynamic does it need to be?  It is not
like the
>>>>>>> upgrade options change minute by minute.  These change slowly,
at the
>>>>>>> pace of our release cycle, so every few months.
>>>>>>
>>>>>> Yes, and traffic is a key factor here. With potentially hundreds
of millions of clients hitting the servers, the biggest problem is not re-implementing the
update service as a web service, but serving it efficiently. And indeed I agree that staticizing
the results somehow would be good to do, since we have a relatively low number of possible
answers with respect to the number of requests.
>>>>>
>>>>> Oliver requested removal of update32 from DNS on INFRA-5112 and now Infra
is requesting PPMC agreement.
>>>>>
>>>>> Is now a time to discuss cleaning up all of the staroffice urls here:
>>>>>
>>>>> update.services               CNAME     sd-web4.staroffice.de.
>>>>> update23.services             CNAME     sd-web2.staroffice.de.
>>>>> update24.services             CNAME     sd-web2.staroffice.de.
>>>>> update30.services             CNAME     sd-web2.staroffice.de.
>>>>> update31.services             CNAME     sd-web2.staroffice.de.
>>>>> update32.services             CNAME     www.openoffice.org.
>>>>> update33.services             CNAME     sd-web2.staroffice.de.
>>>>> update34.services             CNAME     www.openoffice.org.
>>>>> update35.services             CNAME     www.openoffice.org.
>>>>> update36.services             CNAME     www.openoffice.org.
>>>>> update38.services             CNAME     www.openoffice.org.
>>>>>
>>>>> update32 is the proposed change in the JIRA issue.
>>>>>
>>>>> update33 is the added removal.
>>>>>
>>>>> What about update, update23, update24, update30, update31?
>>>>>
>>>>> Should we do anything now as well?
>>>>>
>>>>
>>>> I suppose returning errors from *.openoffice.org is no worse than
>>>> returning errors from *.staroffice.de.  And if we do that we can
>>>> handle these URL's more gracefully in the future if we want to.
>>>
>>> It might be nicer to return a 404 rather than timing out on a non-responsive
ip address.
>>>
>>> Oliver or Kay will need to confirm what will happen.
>>
>> I would like to see a 404 for all currently unused updateX*.services URLs.
>> The former OOo versions which would get in contact with these URLs should handle
such replies.
>
> The following are current in ooo-site/trunk/content/projects/.
>
> update:
> ProductUpdateService    aoo341
>
> update30:
> ProductUpdateService
>
> update34:
> ProductUpdateService
>
> update35:
> ProductUpdateService
>
> update36:
> ProductUpdateService
>
> update38:
> ProductUpdateService
>
> (1) Are update/ProductUpdateSerice and update30/ProductUpdateService ready?
>

They can be created quickly, based on available time of volunteers.
But if we have Infra now ready to act on the redirection now, let's
take advantage of that now, while we have that opportunity.

> (2) Currently all 404s on openoffice.org go here:
>
>    ErrorDocument 404 /docs/custom_404.html
>
> Is that acceptable? Or must we use a real 404 response?
>

Please redirect them to where they would actually live if we wanted to
go live with then. e.g., the appropriate directory under
ooo-site/content/projects/updateXX

In other words, treat them analogously to how we treat the others.
That way they will indeed give 404's now and then we can update then
for real without requiring intervention from Infra.

Thanks,

-Rob

> Regards,
> Dave
>
>>
>> Best regards, Oliver.
>>
>>
>

Mime
View raw message