Open Stack

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.