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. > >> - 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/
