Open Stack

Clint Byrum <clint at fewbar.com> wrote on 11/19/2013 04:28:31 PM:
> From: Clint Byrum <clint at fewbar.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>, 
> Date: 11/19/2013 04:30 PM
> Subject: Re: [openstack-dev] [Heat] HOT software configuration 
> refined after design summit discussions
> 
> Excerpts from Steve Baker's message of 2013-11-19 13:06:21 -0800:
> > On 11/20/2013 09:50 AM, Clint Byrum wrote:
> > > Excerpts from Steve Baker's message of 2013-11-18 12:52:04 -0800:
> > >> Regarding apply_config/remove_config, if a SoftwareApplier resource 
is
> > >> deleted it should trigger any remove_config and wait for the server 
to
> > >> acknowledge when that is complete. This allows for any
> > >> evacuation/deregistering workloads to be executed.
> > >>
> > > I'm a little worried about the road that leads us down. Most 
configuration
> > > software defines forward progress only. Meaning, if you want 
something
> > > not there, you don't remove it from your assertions, you assert that 
it
> > > is not there.

I am worried too.  But I do not entirely follow your reasoning.  When I 
UPDATE a stack with a new template, am I supposed to write in that 
template not just what I want the stack to be but also how that differs 
from what it currently is?  That is not REST.  Not that I am a total REST 
zealot, but I am a fan of managing in terms of desired state.  But I agree 
there is a conflict between defining a 'remove' operation and the "forward 
progress only" mindset of most config tooling.

> > > ...
> > A specific use-case I'm trying to address here is tripleo doing an
> > update-replace on a nova compute node. The remove_config contains the
> > workload to evacuate VMs and signal heat when the node is ready to be
> > shut down. This is more involved than just "uninstall the things".
> > 
> > Could you outline in some more detail how you think this could be 
done?
> > 
> 
> So for that we would not remove the software configuration for the
> nova-compute, we would assert that the machine needs vms evacuated.
> We want evacuation to be something we explicitly do, not a side effect
> of deleting things.

Really?  You want to force the user to explicitly say "evacuate the VMs" 
in all the various ways a host deletion can happen?  E.g., when an 
autoscaling group of hosts shrinks?

> Perhaps having delete hooks for starting delete
> work-flows is right, but it set off a red flag for me so I want to make
> sure we think it through.
> 
> Also IIRC, evacuation is not necessarily an in-instance thing. It looks
> more like the weird thing we've been talking about lately which is
> "how do we orchestrate tenant API's":
> 
> https://etherpad.openstack.org/p/orchestrate-tenant-apis

This looks promising to me.

Regards,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131120/9162825c/attachment.html>