Excerpts from James Slagle's message of 2014-02-12 05:18:31 -0800: > On Tue, Feb 11, 2014 at 12:22 AM, Clint Byrum <cl...@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? >
Thanks for reading it James. We've talked about having an image ID in the Metadata that may or may not be the same image ID that is in the server properties to signify that we want the machine to update itself from said image. That would already be covered by the general "I'm done configuring myself" wait condition. In this case, there is no pending Heat action to prevent when we're just updating metadata, so I think we already handle this situation. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
