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
