Another scaling down/update use case: Say I have a pool of ssh servers for users to use (compute cluster login nodes). Autoscaling up is easy. Just launch a new node and add it to the load balancer.
Scaling down/updating is harder. It should ideally: * Set the admin state on the load balancer for the node, ensuring no new connections go to the node. * Contact the node or the balancer and ensure all outstanding connections are complete. Wait for it. This could be a long long time. * Destroy or update the node Thanks, Kevin ________________________________________ From: Clint Byrum [cl...@fewbar.com] Sent: Tuesday, February 11, 2014 8:13 AM To: openstack-dev Subject: Re: [openstack-dev] [Heat] in-instance update hooks Excerpts from Steven Dake's message of 2014-02-11 07:19:19 -0800: > On 02/10/2014 10:22 PM, Clint Byrum wrote: > > Hi, so in the previous thread about rolling updates it became clear that > > having in-instance control over updates is a more fundamental idea than > > I had previously believed. During an update, Heat does things to servers > > that may interrupt the server's purpose, and that may cause it to fail > > subsequent things in the graph. > > > > Specifically, in TripleO we have compute nodes that we are managing. > > Before rebooting a machine, we want to have a chance to live-migrate > > workloads if possible, or evacuate in the simpler case, before the node > > is rebooted. Also in the case of a Galera DB where we may even be running > > degraded, we want to ensure that we have quorum before proceeding. > > > > I've filed a blueprint for this functionality: > > > > https://blueprints.launchpad.net/heat/+spec/update-hooks > > > > I've cobbled together a spec here, and I would very much welcome > > edits/comments/etc: > > > > https://etherpad.openstack.org/p/heat-update-hooks > Clint, > > I read through your etherpad and think there is a relationship to a use > case for scaling. It would be sweet if both these cases could use the > same model and tooling. At the moment in an autoscaling group, when you > want to scale "down" there is no way to quiesce the node before killing > the VM. It is the same problem you have with Galera, except your > scenario involves an update. > > I'm not clear how the proposed design could be made to fit this > particular use case. Do you see a way it can fill both roles so we > don't have two different ways to do essentially the same thing? > I see scaling down as an update to a nested stack which contains all of the members of the scaling group. So if we start focusing on scaling stacks, as Zane suggested in the rolling updates thread, then the author of said stack would add action_hooks to the resources that are scaled. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev