I guess the API should send a 202 Accepted once called. If possible there
should be a way to notify clients once the process completes, may be via a
callback endpoint.
Regards,
Chamila de Alwis
Committer and PMC Member - Apache Stratos
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
On Mon, Dec 21, 2015 at 12:46 AM, Imesh Gunaratne <im...@apache.org> wrote:
> A good proposal Sajith!
>
> In addition to the points you have mentioned we might also need to change
> the status of the cluster to "In Maintenance" (or any other suitable) at
> the time this is executed. This can be shown in the UI topology view.
>
> Moreover we might also need to consider following:
> - Terminate this process if an application un-deployment process is
> triggered by the user.
> - Disable application, cartridge, deployment policy, application policy
> update operations until this process is completed.
>
> Thanks
>
> On Tue, Dec 15, 2015 at 10:14 PM, Isuru Haththotuwa <isu...@apache.org>
> wrote:
>
>> Hi Sajith,
>>
>> On Tue, Dec 15, 2015 at 5:41 PM, Sajith Kariyawasam <saj...@wso2.com>
>> wrote:
>>
>>> Hi Devs,
>>>
>>> At the moment in a Stratos deployment there is no easy way to do a
>>> rolling update on a service cluster. One has to manually terminate all the
>>> running instances of the cluster, after updating images / puppet master
>>> with relevant fixes, and then autoscaler will spawn new instances with the
>>> latest image. But if the cluster consists of a very large number of
>>> instances, manual process would be a tedious task, hence we had some
>>> discussions on automating this. I and Isuru had a discussion on this and
>>> came up with an initial design. Please find the details below.
>>>
>>> Rolling update feature will be available through CLI,
>>> for eg: *update-cluster <application_id> <cluster_id>
>>> [<image_id>]*
>>>
>>> On update-cluster CLI command, following things would happen internally.
>>> - Disable autoscaling
>>> - Update cartridge definition if necessary (applies only for Kubernetes)
>>>
>> AFAIU, this is applicable for VMs as well; say when we need to patch the
>> OS, etc.
>>
>>> - Terminate one member of the cluster
>>> - Wait for new member's member activated
>>> - Continue terminating all the members
>>> - After successful update, re-enable autoscaling
>>>
>>> CLI operation invokes a new API, which will be added to the
>>> "StratosApiV41" (@PUT /cluster/{clusterId}), and that Invokes a new service
>>> operation added to AutoscalerServiceImpl,
>>> which contains the logic (moving active members to termination pending
>>> list)
>>>
>> As the update is done upon a cluster in a particular application, AFAIU
>> this API should take the application id as a path parameter (or any other
>> suitable way) as well. WDYT?
>>
>>>
>>> Having a new API instead of writing the logic in a client tool will make
>>> things much cleaner and consistent and also we can easily use that API to
>>> provide rolling update feature via Stratos UI in future.
>>>
>> +1
>>
>>>
>>> Appreciate your thoughts on this.
>>>
>>> Thanks,
>>> Sajith
>>>
>>>
>>> --
>>> Sajith Kariyawasam
>>> *Committer and PMC member, Apache Stratos, *
>>> *WSO2 Inc.; http://wso2.com <http://wso2.com>*
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Mobile: 0772269575-- <0772269575> <0772269575>Thanks and Regards,Isuru
>>> H. <0772269575> +94 716 358 048 <0772269575> <http://wso2.com/>
>>> <http://wso2.com/>*
>>>
>>
>
>
> --
> Imesh Gunaratne
>
> Senior Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
