You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Lakmal Warusawithana <la...@wso2.com> on 2014/01/15 17:48:55 UTC
[Discuss] Introducing patching mode
Hi,
We need to come up with, how do we going to patch/upgrade cartridges. Here
what I got in my mind.
- first devOps should update puppet manifest of the relevant cartridge
that need to patch or upgrade that need to be applied.
- Then from the devOps interface (both in CLI and UI) we should provide
interface to set relevant service cluster (basically a cartridge) to
patching mode.
- When it set, SM should get all member information from the topology
and start setting up existing cartridge instances to patching mode. It will
get all current members into a queue and set one instance into patching
mode. SM can call CC to set relevant instance topology to patching mode.
- Then auto scaler will get this information via topology and create an
extra new instance from that cartridge, which will come with all
patch/upgrade from the puppet.
- After this extra instance come active, AS will gracefully shutdown
patching mode instance.
- SM will continue this until all old instance gracefully shutdown.
With this, we can guarantee no downtimes for services that undergoing with
patching state. Please share your thoughts?
PS: Please note that this is not the artifact update. Artifact updates are
real time and there is no downtime at all. This is only applied patches,
security updates ..etc which required restart services/instances.
thanks
--
Lakmal Warusawithana
Software Architect; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: [Discuss] Introducing patching mode
Posted by Udara Liyanage <ud...@wso2.com>.
If we started to patch while auto scaler is scaling up (spinning up more
instances) then it will also cause problems since we have to again patch
the new instances. Either we should stop running scaling up rules while
patching or we can assume that the devops who does the patching is smart
enough to patch when the load is high.
Another way may be to let the devops configure the patching method like
one-by-one, all-once etc... (similar to the autoscaling algorithms)
On Fri, Jan 17, 2014 at 4:23 AM, Lakmal Warusawithana <la...@wso2.com>wrote:
> Hi Damitha,
>
>
>
> On Fri, Jan 17, 2014 at 2:49 PM, damitha kumarage <da...@gmail.com>wrote:
>
>> Hi,
>> +1 Lakmal for the patch/upgrade strategy. Since this is new work why
>> don't we come with a good algorithm incorporating ideas put by Reka, Isuru
>> and Udara and whatever improvements we can think of?
>>
>> Also we need to think of the impact on the users of the cluster under
>> consideration. For example at one moment, instance already applied with the
>> patch run with new code and the one still in the queue run with old code.
>>
>> Also see my inline comment below
>>
>>
>> On Wed, Jan 15, 2014 at 10:18 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>>
>>> Hi,
>>>
>>> We need to come up with, how do we going to patch/upgrade cartridges.
>>> Here what I got in my mind.
>>>
>>>
>>> - first devOps should update puppet manifest of the relevant
>>> cartridge that need to patch or upgrade that need to be applied.
>>> - Then from the devOps interface (both in CLI and UI) we should
>>> provide interface to set relevant service cluster (basically a cartridge)
>>> to patching mode.
>>> - When it set, SM should get all member information from the
>>> topology and start setting up existing cartridge instances to patching
>>> mode. It will get all current members into a queue and set one instance
>>> into patching mode. SM can call CC to set relevant instance topology to
>>> patching mode.
>>>
>>> It is more appropriate to say that whole cluster is in patching mode
>> instead of the one or two being patched at the moment.
>>
>
> Then this cluster having the downtime. Thats is big impact.
>
>
>>
>> Damitha
>>
>>>
>>> - Then auto scaler will get this information via topology and create
>>> an extra new instance from that cartridge, which will come with all
>>> patch/upgrade from the puppet.
>>> - After this extra instance come active, AS will gracefully shutdown
>>> patching mode instance.
>>> - SM will continue this until all old instance gracefully shutdown.
>>>
>>> With this, we can guarantee no downtimes for services that undergoing
>>> with patching state. Please share your thoughts?
>>>
>>> PS: Please note that this is not the artifact update. Artifact updates
>>> are real time and there is no downtime at all. This is only applied
>>> patches, security updates ..etc which required restart services/instances.
>>>
>>> thanks
>>>
>>> --
>>> Lakmal Warusawithana
>>> Software Architect; WSO2 Inc.
>>> Mobile : +94714289692
>>> Blog : http://lakmalsview.blogspot.com/
>>>
>>>
>>
>>
>> --
>> __________________________________________________________________
>> Damitha Kumarage
>> http://people.apache.org/
>> __________________________________________________________________
>>
>
>
>
> --
> Lakmal Warusawithana
> Software Architect; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
--
Udara Liyanage
Software Engineer
WSO2, Inc.: http://wso2.com
lean. enterprise. middleware
web: http://udaraliyanage.wordpress.com
phone: +94 71 443 6897
Re: [Discuss] Introducing patching mode
Posted by Lakmal Warusawithana <la...@wso2.com>.
Hi Damitha,
On Fri, Jan 17, 2014 at 2:49 PM, damitha kumarage <da...@gmail.com>wrote:
> Hi,
> +1 Lakmal for the patch/upgrade strategy. Since this is new work why don't
> we come with a good algorithm incorporating ideas put by Reka, Isuru and
> Udara and whatever improvements we can think of?
>
> Also we need to think of the impact on the users of the cluster under
> consideration. For example at one moment, instance already applied with the
> patch run with new code and the one still in the queue run with old code.
>
> Also see my inline comment below
>
>
> On Wed, Jan 15, 2014 at 10:18 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>
>> Hi,
>>
>> We need to come up with, how do we going to patch/upgrade cartridges.
>> Here what I got in my mind.
>>
>>
>> - first devOps should update puppet manifest of the relevant
>> cartridge that need to patch or upgrade that need to be applied.
>> - Then from the devOps interface (both in CLI and UI) we should
>> provide interface to set relevant service cluster (basically a cartridge)
>> to patching mode.
>> - When it set, SM should get all member information from the topology
>> and start setting up existing cartridge instances to patching mode. It will
>> get all current members into a queue and set one instance into patching
>> mode. SM can call CC to set relevant instance topology to patching mode.
>>
>> It is more appropriate to say that whole cluster is in patching mode
> instead of the one or two being patched at the moment.
>
Then this cluster having the downtime. Thats is big impact.
>
> Damitha
>
>>
>> - Then auto scaler will get this information via topology and create
>> an extra new instance from that cartridge, which will come with all
>> patch/upgrade from the puppet.
>> - After this extra instance come active, AS will gracefully shutdown
>> patching mode instance.
>> - SM will continue this until all old instance gracefully shutdown.
>>
>> With this, we can guarantee no downtimes for services that undergoing
>> with patching state. Please share your thoughts?
>>
>> PS: Please note that this is not the artifact update. Artifact updates
>> are real time and there is no downtime at all. This is only applied
>> patches, security updates ..etc which required restart services/instances.
>>
>> thanks
>>
>> --
>> Lakmal Warusawithana
>> Software Architect; WSO2 Inc.
>> Mobile : +94714289692
>> Blog : http://lakmalsview.blogspot.com/
>>
>>
>
>
> --
> __________________________________________________________________
> Damitha Kumarage
> http://people.apache.org/
> __________________________________________________________________
>
--
Lakmal Warusawithana
Software Architect; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: [Discuss] Introducing patching mode
Posted by damitha kumarage <da...@gmail.com>.
Hi,
+1 Lakmal for the patch/upgrade strategy. Since this is new work why don't
we come with a good algorithm incorporating ideas put by Reka, Isuru and
Udara and whatever improvements we can think of?
Also we need to think of the impact on the users of the cluster under
consideration. For example at one moment, instance already applied with the
patch run with new code and the one still in the queue run with old code.
Also see my inline comment below
On Wed, Jan 15, 2014 at 10:18 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
> Hi,
>
> We need to come up with, how do we going to patch/upgrade cartridges. Here
> what I got in my mind.
>
>
> - first devOps should update puppet manifest of the relevant cartridge
> that need to patch or upgrade that need to be applied.
> - Then from the devOps interface (both in CLI and UI) we should
> provide interface to set relevant service cluster (basically a cartridge)
> to patching mode.
> - When it set, SM should get all member information from the topology
> and start setting up existing cartridge instances to patching mode. It will
> get all current members into a queue and set one instance into patching
> mode. SM can call CC to set relevant instance topology to patching mode.
>
> It is more appropriate to say that whole cluster is in patching mode
instead of the one or two being patched at the moment.
Damitha
>
> - Then auto scaler will get this information via topology and create
> an extra new instance from that cartridge, which will come with all
> patch/upgrade from the puppet.
> - After this extra instance come active, AS will gracefully shutdown
> patching mode instance.
> - SM will continue this until all old instance gracefully shutdown.
>
> With this, we can guarantee no downtimes for services that undergoing with
> patching state. Please share your thoughts?
>
> PS: Please note that this is not the artifact update. Artifact updates are
> real time and there is no downtime at all. This is only applied patches,
> security updates ..etc which required restart services/instances.
>
> thanks
>
> --
> Lakmal Warusawithana
> Software Architect; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
--
__________________________________________________________________
Damitha Kumarage
http://people.apache.org/
__________________________________________________________________
Re: [Discuss] Introducing patching mode
Posted by Udara Liyanage <ud...@wso2.com>.
+1
When there are high number of instances in the cloud, it will take a long
time to update all instances if we patch instances one by one. When there
are many (m) members for a cluster we can patch n<m number of instances at
once. We may be able to come up with a good approach as this graduates as
Isuru said. As the startup this is good.
On Wed, Jan 15, 2014 at 11:52 PM, Isuru Haththotuwa <is...@wso2.com> wrote:
> +1 For the approach. We may need to add improvements such as detect if OS
> restart is required, and if in a cluster with more than one member, not
> terminate and re-spawn but restart the service, etc. But those things can
> be gradually added. This is a good approach to start with.
>
>
> On Thu, Jan 16, 2014 at 9:45 AM, Reka Thirunavukkarasu <re...@wso2.com>wrote:
>
>> Hi
>>
>>
>> On Thu, Jan 16, 2014 at 9:20 AM, Lakmal Warusawithana <la...@wso2.com>wrote:
>>
>>> Hi Reka,
>>>
>>>
>>> On Wed, Jan 15, 2014 at 11:18 PM, Reka Thirunavukkarasu <re...@wso2.com>wrote:
>>>
>>>> Hi
>>>>
>>>> +1. Nice thoughts to implement cartridge patching/upgrade mechanism
>>>> with stratos.
>>>>
>>>>
>>>> On Wed, Jan 15, 2014 at 10:18 PM, Lakmal Warusawithana <lakmal@wso2.com
>>>> > wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We need to come up with, how do we going to patch/upgrade cartridges.
>>>>> Here what I got in my mind.
>>>>>
>>>>>
>>>>> - first devOps should update puppet manifest of the relevant
>>>>> cartridge that need to patch or upgrade that need to be applied.
>>>>> - Then from the devOps interface (both in CLI and UI) we should
>>>>> provide interface to set relevant service cluster (basically a cartridge)
>>>>> to patching mode.
>>>>> - When it set, SM should get all member information from the
>>>>> topology and start setting up existing cartridge instances to patching
>>>>> mode. It will get all current members into a queue and set one instance
>>>>> into patching mode. SM can call CC to set relevant instance topology to
>>>>> patching mode.
>>>>> - Then auto scaler will get this information via topology and
>>>>> create an extra new instance from that cartridge, which will come with all
>>>>> patch/upgrade from the puppet.
>>>>>
>>>>> Can't we use the same patch mode instance to execute the puppet to get
>>>> the upgrade/patch via a topic event? So that, the instance which is there
>>>> in patching state will become activated by cartridge agent once the patch
>>>> got applied properly. Then, SM can remove the particular member from the
>>>> queue and keep track of the others in the queue. By using the same
>>>> instance, we can optimize the resources for the user.
>>>>
>>>
>>> I also thought this scenario but here is my concerns. If we set one
>>> instance in patching mode and remove it from the LB, at that movement
>>> particular cluster will running one instance short. (also if its max=1
>>> scenario we cant do it.). Next concern is if this patch required OS
>>> restart? e.g. security patch for OS. So solution for these scenarios is we
>>> have to have two patching mode, which AS life put more complex. Thats why I
>>> suggest having simple single way to handle all patching scenario.
>>>
>>
>> +1. The mentioned approach as bringing up new instance with patching will
>> be simple in this case. When billing gets introduced, anyone can ignore
>> billing or not for the patching mode depends on their environment.
>>
>> Thanks,
>> Reka
>>
>>>
>>>>> - After this extra instance come active, AS will gracefully
>>>>> shutdown patching mode instance.
>>>>> - SM will continue this until all old instance gracefully shutdown.
>>>>>
>>>>> With this, we can guarantee no downtimes for services that undergoing
>>>>> with patching state. Please share your thoughts?
>>>>>
>>>>> PS: Please note that this is not the artifact update. Artifact updates
>>>>> are real time and there is no downtime at all. This is only applied
>>>>> patches, security updates ..etc which required restart services/instances.
>>>>>
>>>>
>>>> Thanks,
>>>> Reka
>>>>
>>>>>
>>>>> thanks
>>>>>
>>>>> --
>>>>> Lakmal Warusawithana
>>>>> Software Architect; WSO2 Inc.
>>>>> Mobile : +94714289692
>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Reka Thirunavukkarasu
>>>> Software Engineer,
>>>> WSO2, Inc.:http://wso2.com,
>>>> Mobile: +94776442007
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Lakmal Warusawithana
>>> Software Architect; WSO2 Inc.
>>> Mobile : +94714289692
>>> Blog : http://lakmalsview.blogspot.com/
>>>
>>>
>>
>>
>> --
>> Reka Thirunavukkarasu
>> Software Engineer,
>> WSO2, Inc.:http://wso2.com,
>> Mobile: +94776442007
>>
>>
>>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
>
--
Udara Liyanage
Software Engineer
WSO2, Inc.: http://wso2.com
lean. enterprise. middleware
web: http://udaraliyanage.wordpress.com
phone: +94 71 443 6897
Re: [Discuss] Introducing patching mode
Posted by Isuru Haththotuwa <is...@wso2.com>.
+1 For the approach. We may need to add improvements such as detect if OS
restart is required, and if in a cluster with more than one member, not
terminate and re-spawn but restart the service, etc. But those things can
be gradually added. This is a good approach to start with.
On Thu, Jan 16, 2014 at 9:45 AM, Reka Thirunavukkarasu <re...@wso2.com>wrote:
> Hi
>
>
> On Thu, Jan 16, 2014 at 9:20 AM, Lakmal Warusawithana <la...@wso2.com>wrote:
>
>> Hi Reka,
>>
>>
>> On Wed, Jan 15, 2014 at 11:18 PM, Reka Thirunavukkarasu <re...@wso2.com>wrote:
>>
>>> Hi
>>>
>>> +1. Nice thoughts to implement cartridge patching/upgrade mechanism with
>>> stratos.
>>>
>>>
>>> On Wed, Jan 15, 2014 at 10:18 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> We need to come up with, how do we going to patch/upgrade cartridges.
>>>> Here what I got in my mind.
>>>>
>>>>
>>>> - first devOps should update puppet manifest of the relevant
>>>> cartridge that need to patch or upgrade that need to be applied.
>>>> - Then from the devOps interface (both in CLI and UI) we should
>>>> provide interface to set relevant service cluster (basically a cartridge)
>>>> to patching mode.
>>>> - When it set, SM should get all member information from the
>>>> topology and start setting up existing cartridge instances to patching
>>>> mode. It will get all current members into a queue and set one instance
>>>> into patching mode. SM can call CC to set relevant instance topology to
>>>> patching mode.
>>>> - Then auto scaler will get this information via topology and
>>>> create an extra new instance from that cartridge, which will come with all
>>>> patch/upgrade from the puppet.
>>>>
>>>> Can't we use the same patch mode instance to execute the puppet to get
>>> the upgrade/patch via a topic event? So that, the instance which is there
>>> in patching state will become activated by cartridge agent once the patch
>>> got applied properly. Then, SM can remove the particular member from the
>>> queue and keep track of the others in the queue. By using the same
>>> instance, we can optimize the resources for the user.
>>>
>>
>> I also thought this scenario but here is my concerns. If we set one
>> instance in patching mode and remove it from the LB, at that movement
>> particular cluster will running one instance short. (also if its max=1
>> scenario we cant do it.). Next concern is if this patch required OS
>> restart? e.g. security patch for OS. So solution for these scenarios is we
>> have to have two patching mode, which AS life put more complex. Thats why I
>> suggest having simple single way to handle all patching scenario.
>>
>
> +1. The mentioned approach as bringing up new instance with patching will
> be simple in this case. When billing gets introduced, anyone can ignore
> billing or not for the patching mode depends on their environment.
>
> Thanks,
> Reka
>
>>
>>>> - After this extra instance come active, AS will gracefully
>>>> shutdown patching mode instance.
>>>> - SM will continue this until all old instance gracefully shutdown.
>>>>
>>>> With this, we can guarantee no downtimes for services that undergoing
>>>> with patching state. Please share your thoughts?
>>>>
>>>> PS: Please note that this is not the artifact update. Artifact updates
>>>> are real time and there is no downtime at all. This is only applied
>>>> patches, security updates ..etc which required restart services/instances.
>>>>
>>>
>>> Thanks,
>>> Reka
>>>
>>>>
>>>> thanks
>>>>
>>>> --
>>>> Lakmal Warusawithana
>>>> Software Architect; WSO2 Inc.
>>>> Mobile : +94714289692
>>>> Blog : http://lakmalsview.blogspot.com/
>>>>
>>>>
>>>
>>>
>>> --
>>> Reka Thirunavukkarasu
>>> Software Engineer,
>>> WSO2, Inc.:http://wso2.com,
>>> Mobile: +94776442007
>>>
>>>
>>>
>>
>>
>> --
>> Lakmal Warusawithana
>> Software Architect; WSO2 Inc.
>> Mobile : +94714289692
>> Blog : http://lakmalsview.blogspot.com/
>>
>>
>
>
> --
> Reka Thirunavukkarasu
> Software Engineer,
> WSO2, Inc.:http://wso2.com,
> Mobile: +94776442007
>
>
>
--
Thanks and Regards,
Isuru H.
+94 716 358 048* <http://wso2.com/>*
Re: [Discuss] Introducing patching mode
Posted by Reka Thirunavukkarasu <re...@wso2.com>.
Hi
On Thu, Jan 16, 2014 at 9:20 AM, Lakmal Warusawithana <la...@wso2.com>wrote:
> Hi Reka,
>
>
> On Wed, Jan 15, 2014 at 11:18 PM, Reka Thirunavukkarasu <re...@wso2.com>wrote:
>
>> Hi
>>
>> +1. Nice thoughts to implement cartridge patching/upgrade mechanism with
>> stratos.
>>
>>
>> On Wed, Jan 15, 2014 at 10:18 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>>
>>> Hi,
>>>
>>> We need to come up with, how do we going to patch/upgrade cartridges.
>>> Here what I got in my mind.
>>>
>>>
>>> - first devOps should update puppet manifest of the relevant
>>> cartridge that need to patch or upgrade that need to be applied.
>>> - Then from the devOps interface (both in CLI and UI) we should
>>> provide interface to set relevant service cluster (basically a cartridge)
>>> to patching mode.
>>> - When it set, SM should get all member information from the
>>> topology and start setting up existing cartridge instances to patching
>>> mode. It will get all current members into a queue and set one instance
>>> into patching mode. SM can call CC to set relevant instance topology to
>>> patching mode.
>>> - Then auto scaler will get this information via topology and create
>>> an extra new instance from that cartridge, which will come with all
>>> patch/upgrade from the puppet.
>>>
>>> Can't we use the same patch mode instance to execute the puppet to get
>> the upgrade/patch via a topic event? So that, the instance which is there
>> in patching state will become activated by cartridge agent once the patch
>> got applied properly. Then, SM can remove the particular member from the
>> queue and keep track of the others in the queue. By using the same
>> instance, we can optimize the resources for the user.
>>
>
> I also thought this scenario but here is my concerns. If we set one
> instance in patching mode and remove it from the LB, at that movement
> particular cluster will running one instance short. (also if its max=1
> scenario we cant do it.). Next concern is if this patch required OS
> restart? e.g. security patch for OS. So solution for these scenarios is we
> have to have two patching mode, which AS life put more complex. Thats why I
> suggest having simple single way to handle all patching scenario.
>
+1. The mentioned approach as bringing up new instance with patching will
be simple in this case. When billing gets introduced, anyone can ignore
billing or not for the patching mode depends on their environment.
Thanks,
Reka
>
>>> - After this extra instance come active, AS will gracefully shutdown
>>> patching mode instance.
>>> - SM will continue this until all old instance gracefully shutdown.
>>>
>>> With this, we can guarantee no downtimes for services that undergoing
>>> with patching state. Please share your thoughts?
>>>
>>> PS: Please note that this is not the artifact update. Artifact updates
>>> are real time and there is no downtime at all. This is only applied
>>> patches, security updates ..etc which required restart services/instances.
>>>
>>
>> Thanks,
>> Reka
>>
>>>
>>> thanks
>>>
>>> --
>>> Lakmal Warusawithana
>>> Software Architect; WSO2 Inc.
>>> Mobile : +94714289692
>>> Blog : http://lakmalsview.blogspot.com/
>>>
>>>
>>
>>
>> --
>> Reka Thirunavukkarasu
>> Software Engineer,
>> WSO2, Inc.:http://wso2.com,
>> Mobile: +94776442007
>>
>>
>>
>
>
> --
> Lakmal Warusawithana
> Software Architect; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
--
Reka Thirunavukkarasu
Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007
Re: [Discuss] Introducing patching mode
Posted by Lakmal Warusawithana <la...@wso2.com>.
Hi Reka,
On Wed, Jan 15, 2014 at 11:18 PM, Reka Thirunavukkarasu <re...@wso2.com>wrote:
> Hi
>
> +1. Nice thoughts to implement cartridge patching/upgrade mechanism with
> stratos.
>
>
> On Wed, Jan 15, 2014 at 10:18 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
>
>> Hi,
>>
>> We need to come up with, how do we going to patch/upgrade cartridges.
>> Here what I got in my mind.
>>
>>
>> - first devOps should update puppet manifest of the relevant
>> cartridge that need to patch or upgrade that need to be applied.
>> - Then from the devOps interface (both in CLI and UI) we should
>> provide interface to set relevant service cluster (basically a cartridge)
>> to patching mode.
>> - When it set, SM should get all member information from the topology
>> and start setting up existing cartridge instances to patching mode. It will
>> get all current members into a queue and set one instance into patching
>> mode. SM can call CC to set relevant instance topology to patching mode.
>> - Then auto scaler will get this information via topology and create
>> an extra new instance from that cartridge, which will come with all
>> patch/upgrade from the puppet.
>>
>> Can't we use the same patch mode instance to execute the puppet to get
> the upgrade/patch via a topic event? So that, the instance which is there
> in patching state will become activated by cartridge agent once the patch
> got applied properly. Then, SM can remove the particular member from the
> queue and keep track of the others in the queue. By using the same
> instance, we can optimize the resources for the user.
>
I also thought this scenario but here is my concerns. If we set one
instance in patching mode and remove it from the LB, at that movement
particular cluster will running one instance short. (also if its max=1
scenario we cant do it.). Next concern is if this patch required OS
restart? e.g. security patch for OS. So solution for these scenarios is we
have to have two patching mode, which AS life put more complex. Thats why I
suggest having simple single way to handle all patching scenario.
>
>> - After this extra instance come active, AS will gracefully shutdown
>> patching mode instance.
>> - SM will continue this until all old instance gracefully shutdown.
>>
>> With this, we can guarantee no downtimes for services that undergoing
>> with patching state. Please share your thoughts?
>>
>> PS: Please note that this is not the artifact update. Artifact updates
>> are real time and there is no downtime at all. This is only applied
>> patches, security updates ..etc which required restart services/instances.
>>
>
> Thanks,
> Reka
>
>>
>> thanks
>>
>> --
>> Lakmal Warusawithana
>> Software Architect; WSO2 Inc.
>> Mobile : +94714289692
>> Blog : http://lakmalsview.blogspot.com/
>>
>>
>
>
> --
> Reka Thirunavukkarasu
> Software Engineer,
> WSO2, Inc.:http://wso2.com,
> Mobile: +94776442007
>
>
>
--
Lakmal Warusawithana
Software Architect; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: [Discuss] Introducing patching mode
Posted by Reka Thirunavukkarasu <re...@wso2.com>.
Hi
+1. Nice thoughts to implement cartridge patching/upgrade mechanism with
stratos.
On Wed, Jan 15, 2014 at 10:18 PM, Lakmal Warusawithana <la...@wso2.com>wrote:
> Hi,
>
> We need to come up with, how do we going to patch/upgrade cartridges. Here
> what I got in my mind.
>
>
> - first devOps should update puppet manifest of the relevant cartridge
> that need to patch or upgrade that need to be applied.
> - Then from the devOps interface (both in CLI and UI) we should
> provide interface to set relevant service cluster (basically a cartridge)
> to patching mode.
> - When it set, SM should get all member information from the topology
> and start setting up existing cartridge instances to patching mode. It will
> get all current members into a queue and set one instance into patching
> mode. SM can call CC to set relevant instance topology to patching mode.
> - Then auto scaler will get this information via topology and create
> an extra new instance from that cartridge, which will come with all
> patch/upgrade from the puppet.
>
> Can't we use the same patch mode instance to execute the puppet to get the
upgrade/patch via a topic event? So that, the instance which is there in
patching state will become activated by cartridge agent once the patch got
applied properly. Then, SM can remove the particular member from the queue
and keep track of the others in the queue. By using the same instance, we
can optimize the resources for the user.
>
> - After this extra instance come active, AS will gracefully shutdown
> patching mode instance.
> - SM will continue this until all old instance gracefully shutdown.
>
> With this, we can guarantee no downtimes for services that undergoing with
> patching state. Please share your thoughts?
>
> PS: Please note that this is not the artifact update. Artifact updates are
> real time and there is no downtime at all. This is only applied patches,
> security updates ..etc which required restart services/instances.
>
Thanks,
Reka
>
> thanks
>
> --
> Lakmal Warusawithana
> Software Architect; WSO2 Inc.
> Mobile : +94714289692
> Blog : http://lakmalsview.blogspot.com/
>
>
--
Reka Thirunavukkarasu
Software Engineer,
WSO2, Inc.:http://wso2.com,
Mobile: +94776442007