Open Stack

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?

Regards
-steve

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev