Open Stack

On Tue, Feb 11, 2014 at 12:22 AM, Clint Byrum <clint at fewbar.com> 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

I like this approach.

Could this work for the non-reboot required incremental update (via
rsync or whatever) idea that's been discussed as well? I think it'd be
nice if we had a model that worked for both the rebuild case and
incremental case.

What if there was an additional type for actions under action_hooks
called update or incremental (I'm not sure if there is a term for this
in Heat today) in addition to the rebuild and delete action choices
that are already there.

When the instance sees that this action type is pending, it can
perform the update, and then use the wait condition handle to indicate
to Heat that the update is complete vs. using the wait condition
handle to indicate to proceed with the rebuild.

I suppose the instance might need some additional data (such as the
new Image Id) in order to perform the incremental update. Could this
be made available somehow in the metadata structure?

-- 
-- James Slagle
--