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@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
