Open Stack

Excerpts from Mike Spreitzer's message of 2013-11-20 13:46:25 -0800:
> 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.
> 

I am worried about the explosion of possibilities that comes from trying
to deal with all of the diff's possible inside an instance. If there is an
actual REST interface for a thing, then yes, let's use that. For instance,
if we are using docker, there is in fact a very straight forward way to
say "remove entity X". If we are using packages we have the same thing.
However, if we are just trying to write chef configurations, we have to
write reverse chef configurations.

What I meant to convey is "let's give this piece of the interface a lot of
thought". Not "this is wrong to even have." Given a couple of days now,
I think we do need "apply" and "remove". We should also provide really
solid example templates for this concept.

> > > > ...
> > > 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?
> 

Autoscaling doesn't really fly with stateful services IMO. Also for
TripleO's use case, auto-scaling is not really a high priority. Hardware
isn't nearly as easily allocatable as VM's.

Anyway, there is a really complicated work-flow for decomissioning
any stateful service, and it differs wildly between them. I do want to
have a place to define that work-flow and reliably trigger it when it
needs to be triggered. I do not want it to _only_ be available in the
"delete this resource" case, and I also do not want it to _always_
be run in that case, as I may legitimately be destroying the data too.
I need a way to express that intention, and in my mind, the way to do
that is to first complete an evacuation and then delete the thing.

Better ideas are _most_ welcome.