Thanks Kevin, great summary. This is beyond the scope of in-instance notification. I think this is more like the generic notification API that Thomas Herve suggested in the rolling updates thread. It can definitely use the same method for its implementation, and I think it is adjacent to, and not in front of or behind, the in-instance case.
Excerpts from Fox, Kevin M's message of 2014-02-11 09:22:28 -0800: > 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 [[email protected]] > 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 [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
