You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Oliver-Rainer Wittmann <or...@googlemail.com> on 2012/08/03 12:13:08 UTC
[UPDATE SERVICE] dynamic approach [was: Re: [UPDATE SERVICE] activation
of update service for OOo 3.1 and OOo 3.1.1]
Hi,
On 03.08.2012 10:04, Jürgen Schmidt wrote:
> On 8/3/12 9:51 AM, Oliver-Rainer Wittmann wrote:
>> Hi,
>>
>> On 03.08.2012 09:40, Oliver-Rainer Wittmann wrote:
>>>>
>>>> in order to avoid that somebody has missed the stuff ongoing
>>>> regarding the
>>>> update service for OOo 3.1 and OOo 3.1.1:
>>>> In another thread - see [1] - Rob asked for the update service for
>>>> OOo 3.1 and
>>>> OOo 3.1.1. Nobody objects so far. But this was somehow hidden in
>>>> another thread.
>>>> Thus, I am bringing it up to its own thread.
>>>>
>>>> I will start working on this task, if nobody objects.
>>>>
>>>> [1] http://markmail.org/message/3fwnjrk7isyt5wa4
>>>>
>>>>
>>>
>>> No objections so far.
>>> Thus, I will go ahead.
>>>
>>> First, I will ask Apache Infrastructure to establish the needed
>>> redirect from
>>> [2] to [3]. In the meanwhile I will create the corresponding XML
>>> document for
>>> this update service. I am planning to activate it after our Apache
>>> OpenOffice
>>> (incubating) 3.4.1 release.
>>>
>>> [2]
>>> http://update32.services.openoffice.org/ProductUpdateService/check.Update
>>> [3]
>>> http://www.openoffice.org/projects/update32/ProductUpdateService/check.Update
>>>
>>>
>>>
>>
>> I have submitted JIRA issue INFRA-5112 [1] requesting to establish the
>> needed redirect. I am asking Apache Infrastructure to establish the
>> redirect until 2012-08-15 in order to reach out our users of OOo 3.1 and
>> OOo 3.1.1 instance just in time with our planned AOO 3.4.1 release.
>>
>> [1] https://issues.apache.org/jira/browse/INFRA-5112
>>
>
> I think we should start thinking about a more flexible dynamic approach.
> A real web service or script that provides the info on demand and
> dynamically generated based on the parameters. Means we would have one
> Url in the future where we can much easier tweak and extend the
> underlying data instead of new Urls for new releases.
>
> The question is
> - what is posible with the existing infra structure
> - who has the knowledge and interest to work on this
> - ...
>
> Any ideas or opinions
>
Yes, I agree here with Jürgen.
That is the reason why 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.
I also expect to get in contact in person with Apache Infrastructure people in
order to discuss certain prerequisites and requirements.
But, we can start the discussion right now and here on the list.
Thus, anybody who has expertise in creating such a web service and volunteers to
take over this task can get corresponding information about the update function
and the corresponding protocol here and at the wiki [1].
[1] http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol
Best regards, Oliver.
Re: [UPDATE SERVICE] dynamic approach [was: Re: [UPDATE SERVICE] activation of update service for OOo 3.1 and OOo 3.1.1]
Posted by Dave Fisher <da...@comcast.net>.
On Aug 14, 2012, at 12:42 PM, Dave Fisher wrote:
>
> On Aug 14, 2012, at 12:31 PM, Rob Weir wrote:
>
>> On Tue, Aug 14, 2012 at 3:25 PM, Dave Fisher <da...@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 <da...@comcast.net>:
>>>>
>>>>>
>>>>> On Aug 14, 2012, at 11:43 AM, Rob Weir wrote:
>>>>>
>>>>>> On Tue, Aug 14, 2012 at 2:24 PM, Dave Fisher <da...@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?
The DNS is now done. ooo-site may be changed as needed.
>>>
>>
>> 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.
>
> These urls get rewritten by this default rule:
>
> # fallback for proj.openoffice.org/... to openoffice.org/projects/proj/...
> RewriteCond ${lowercase:%{HTTP_HOST}} ^(?!www)(\w+)(?:\.\w+)?\.openoffice\.org$
> RewriteRule ^(.*)$ ${lowercase:%{HTTP_HOST}}$1 [C]
> RewriteRule ^(\w+)(?:\.\w+)?\.openoffice\.org/(.*) http://www.openoffice.org/projects/$1/$2 [NE,L]
>
> We should probably add:
>
> <Directory /projects>
> ErrorDocument 404 default
> </Directory>
>
> Correct me if I'm wrong but that should make anything in that tree return a real 404.
Done and tested. [1] is updated.
Regards,
Dave
https://cwiki.apache.org/confluence/display/OOOUSERS/Open+Infrastructure+Requests
>
> And overrides:
>
> ErrorDocument 404 /docs/custom_404.html
>
>
> Regards,
> Dave
>
>
>
>>
>> Thanks,
>>
>> -Rob
>>
>>> Regards,
>>> Dave
>>>
>>>>
>>>> Best regards, Oliver.
>>>>
>>>>
>>>
>
Re: [UPDATE SERVICE] dynamic approach [was: Re: [UPDATE SERVICE] activation of update service for OOo 3.1 and OOo 3.1.1]
Posted by Dave Fisher <da...@comcast.net>.
On Aug 14, 2012, at 12:31 PM, Rob Weir wrote:
> On Tue, Aug 14, 2012 at 3:25 PM, Dave Fisher <da...@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 <da...@comcast.net>:
>>>
>>>>
>>>> On Aug 14, 2012, at 11:43 AM, Rob Weir wrote:
>>>>
>>>>> On Tue, Aug 14, 2012 at 2:24 PM, Dave Fisher <da...@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.
These urls get rewritten by this default rule:
# fallback for proj.openoffice.org/... to openoffice.org/projects/proj/...
RewriteCond ${lowercase:%{HTTP_HOST}} ^(?!www)(\w+)(?:\.\w+)?\.openoffice\.org$
RewriteRule ^(.*)$ ${lowercase:%{HTTP_HOST}}$1 [C]
RewriteRule ^(\w+)(?:\.\w+)?\.openoffice\.org/(.*) http://www.openoffice.org/projects/$1/$2 [NE,L]
We should probably add:
<Directory /projects>
ErrorDocument 404 default
</Directory>
Correct me if I'm wrong but that should make anything in that tree return a real 404.
And overrides:
ErrorDocument 404 /docs/custom_404.html
Regards,
Dave
>
> Thanks,
>
> -Rob
>
>> Regards,
>> Dave
>>
>>>
>>> Best regards, Oliver.
>>>
>>>
>>
Re: [UPDATE SERVICE] dynamic approach [was: Re: [UPDATE SERVICE]
activation of update service for OOo 3.1 and OOo 3.1.1]
Posted by Rob Weir <ro...@apache.org>.
On Tue, Aug 14, 2012 at 3:25 PM, Dave Fisher <da...@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 <da...@comcast.net>:
>>
>>>
>>> On Aug 14, 2012, at 11:43 AM, Rob Weir wrote:
>>>
>>>> On Tue, Aug 14, 2012 at 2:24 PM, Dave Fisher <da...@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.
>>
>>
>
Re: [UPDATE SERVICE] dynamic approach [was: Re: [UPDATE SERVICE] activation of update service for OOo 3.1 and OOo 3.1.1]
Posted by Dave Fisher <da...@comcast.net>.
On Aug 14, 2012, at 12:09 PM, Oliver-Rainer Wittmann wrote:
> Hi,
>
> Am 14.08.2012 um 20:52 schrieb Dave Fisher <da...@comcast.net>:
>
>>
>> On Aug 14, 2012, at 11:43 AM, Rob Weir wrote:
>>
>>> On Tue, Aug 14, 2012 at 2:24 PM, Dave Fisher <da...@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?
(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?
Regards,
Dave
>
> Best regards, Oliver.
>
>
Re: [UPDATE SERVICE] dynamic approach [was: Re: [UPDATE SERVICE]
activation of update service for OOo 3.1 and OOo 3.1.1]
Posted by Rob Weir <ro...@apache.org>.
On Tue, Aug 14, 2012 at 3:09 PM, Oliver-Rainer Wittmann
<or...@googlemail.com> wrote:
> Hi,
>
> Am 14.08.2012 um 20:52 schrieb Dave Fisher <da...@comcast.net>:
>
>>
>> On Aug 14, 2012, at 11:43 AM, Rob Weir wrote:
>>
>>> On Tue, Aug 14, 2012 at 2:24 PM, Dave Fisher <da...@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.
>
Right. But can we do this this by sending them to openoffice.org to
our ooo-site files? If we can then we'll get an error 404 naturally
that way. And when/if we want to handle them with an XML file then
any committer can do that. But if we generate the errors at the
httpd level then we're back to waiting for Infra to make changes.
Better to arrange it so it is in the project's control.
> Best regards, Oliver.
>
>
Re: [UPDATE SERVICE] dynamic approach [was: Re: [UPDATE SERVICE] activation of update service for OOo 3.1 and OOo 3.1.1]
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
Am 14.08.2012 um 20:52 schrieb Dave Fisher <da...@comcast.net>:
>
> On Aug 14, 2012, at 11:43 AM, Rob Weir wrote:
>
>> On Tue, Aug 14, 2012 at 2:24 PM, Dave Fisher <da...@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.
Best regards, Oliver.
Re: [UPDATE SERVICE] dynamic approach [was: Re: [UPDATE SERVICE] activation of update service for OOo 3.1 and OOo 3.1.1]
Posted by Dave Fisher <da...@comcast.net>.
On Aug 14, 2012, at 11:43 AM, Rob Weir wrote:
> On Tue, Aug 14, 2012 at 2:24 PM, Dave Fisher <da...@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.
Regards,
Dave
>
>
>> Regards,
>> Dave
>>
Re: [UPDATE SERVICE] dynamic approach [was: Re: [UPDATE SERVICE]
activation of update service for OOo 3.1 and OOo 3.1.1]
Posted by Rob Weir <ro...@apache.org>.
On Tue, Aug 14, 2012 at 2:24 PM, Dave Fisher <da...@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.
> Regards,
> Dave
>
Re: [UPDATE SERVICE] dynamic approach [was: Re: [UPDATE SERVICE] activation of update service for OOo 3.1 and OOo 3.1.1]
Posted by Dave Fisher <da...@comcast.net>.
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?
Regards,
Dave
Re: [UPDATE SERVICE] dynamic approach [was: Re: [UPDATE SERVICE]
activation of update service for OOo 3.1 and OOo 3.1.1]
Posted by Andrea Pescetti <pe...@apache.org>.
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.
Regards,
Andrea.
Re: [UPDATE SERVICE] dynamic approach [was: Re: [UPDATE SERVICE]
activation of update service for OOo 3.1 and OOo 3.1.1]
Posted by Rob Weir <ro...@apache.org>.
On Fri, Aug 3, 2012 at 6:13 AM, Oliver-Rainer Wittmann
<or...@googlemail.com> wrote:
> Hi,
>
> On 03.08.2012 10:04, Jürgen Schmidt wrote:
>>
>> On 8/3/12 9:51 AM, Oliver-Rainer Wittmann wrote:
>>>
>>> Hi,
>>>
>>> On 03.08.2012 09:40, Oliver-Rainer Wittmann wrote:
>>>>>
>>>>>
>>>>> in order to avoid that somebody has missed the stuff ongoing
>>>>> regarding the
>>>>> update service for OOo 3.1 and OOo 3.1.1:
>>>>> In another thread - see [1] - Rob asked for the update service for
>>>>> OOo 3.1 and
>>>>> OOo 3.1.1. Nobody objects so far. But this was somehow hidden in
>>>>> another thread.
>>>>> Thus, I am bringing it up to its own thread.
>>>>>
>>>>> I will start working on this task, if nobody objects.
>>>>>
>>>>> [1] http://markmail.org/message/3fwnjrk7isyt5wa4
>>>>>
>>>>>
>>>>
>>>> No objections so far.
>>>> Thus, I will go ahead.
>>>>
>>>> First, I will ask Apache Infrastructure to establish the needed
>>>> redirect from
>>>> [2] to [3]. In the meanwhile I will create the corresponding XML
>>>> document for
>>>> this update service. I am planning to activate it after our Apache
>>>> OpenOffice
>>>> (incubating) 3.4.1 release.
>>>>
>>>> [2]
>>>>
>>>> http://update32.services.openoffice.org/ProductUpdateService/check.Update
>>>> [3]
>>>>
>>>> http://www.openoffice.org/projects/update32/ProductUpdateService/check.Update
>>>>
>>>>
>>>>
>>>
>>> I have submitted JIRA issue INFRA-5112 [1] requesting to establish the
>>> needed redirect. I am asking Apache Infrastructure to establish the
>>> redirect until 2012-08-15 in order to reach out our users of OOo 3.1 and
>>> OOo 3.1.1 instance just in time with our planned AOO 3.4.1 release.
>>>
>>> [1] https://issues.apache.org/jira/browse/INFRA-5112
>>>
>>
>> I think we should start thinking about a more flexible dynamic approach.
>> A real web service or script that provides the info on demand and
>> dynamically generated based on the parameters. Means we would have one
>> Url in the future where we can much easier tweak and extend the
>> underlying data instead of new Urls for new releases.
>>
>> The question is
>> - what is posible with the existing infra structure
>> - who has the knowledge and interest to work on this
>> - ...
>>
>> Any ideas or opinions
>>
>
> Yes, I agree here with Jürgen.
>
> That is the reason why 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.
> I also expect to get in contact in person with Apache Infrastructure people
> in order to discuss certain prerequisites and requirements.
>
> But, we can start the discussion right now and here on the list.
> Thus, anybody who has expertise in creating such a web service and
> volunteers to take over this task can get corresponding information about
> the update function and the corresponding protocol here and at the wiki [1].
>
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.
Getting a live web service hosted brings with it additional concerns
about security, CPU usage, maintenance, etc. I wonder if a simpler
solution would be one that works with the model of the CMS, e.g., a
source document that is transformed into the needed XML update docs.
For example, a source document could be a single document that
defines, in some easily readable notation, the upgrade paths. To make
it easier, it might allow wild cards or defaults for things like
languages and platforms. For example, a notation like this:
version=<3.4.1; lang=en,fr,es.it,de; upgrade=3.4.1
version=<3.3.0; lang=OTHER; upgrade=3.3.0
This could mean:
1) Define upgrade paths for all versions before AOO3.4.1 in
languagesEnglish, Frenchh, Spanish, Italian and German to upgrade to
AOO3.4.1
2) Define upgrade paths for all other languages using versions before
OOo 3.3.0 to upgrade to OOo 3.3.0
Then we would need a script to generate the appropriate XML files,
using this definition file for input. My guess is it starts with a
giant matrix of all of the upgrade paths, languages*versions, and
fills out the matrix according to the definitions above, in order. A
later rule overwrites (dominates) an earlier rule. Then the XML files
are written according to the final matrix.
This should be able to be hooked into the site logic so when someone
edits the definition file and commits it, the updated upgrade XML is
automatically generated.
-Rob
> [1] http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol
>
> Best regards, Oliver.