+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 <[email protected]>wrote: > Hi > > > On Thu, Jan 16, 2014 at 9:20 AM, Lakmal Warusawithana <[email protected]>wrote: > >> Hi Reka, >> >> >> On Wed, Jan 15, 2014 at 11:18 PM, Reka Thirunavukkarasu <[email protected]>wrote: >> >>> Hi >>> >>> +1. Nice thoughts to implement cartridge patching/upgrade mechanism with >>> stratos. >>> >>> >>> On Wed, Jan 15, 2014 at 10:18 PM, Lakmal Warusawithana >>> <[email protected]>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/>*
