Open Stack

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 [clint at 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 at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev