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 <[email protected]>wrote: > Hi Damitha, > > > > On Fri, Jan 17, 2014 at 2:49 PM, damitha kumarage <[email protected]>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 >> <[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. >>> >>> 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
