+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 <[email protected]> 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 <[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/>* > > > -- Udara Liyanage Software Engineer WSO2, Inc.: http://wso2.com lean. enterprise. middleware web: http://udaraliyanage.wordpress.com phone: +94 71 443 6897
