Also see my inline comment belowAlso 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.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?On Wed, Jan 15, 2014 at 10:18 PM, Lakmal Warusawithana <email@example.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 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--