<tt><font size=2>Clint Byrum <clint@fewbar.com> wrote on 11/19/2013
04:28:31 PM:<br>
> From: Clint Byrum <clint@fewbar.com></font></tt>
<br><tt><font size=2>> To: openstack-dev <openstack-dev@lists.openstack.org>,
</font></tt>
<br><tt><font size=2>> Date: 11/19/2013 04:30 PM</font></tt>
<br><tt><font size=2>> Subject: Re: [openstack-dev] [Heat] HOT software
configuration <br>
> refined after design summit discussions</font></tt>
<br><tt><font size=2>> <br>
> Excerpts from Steve Baker's message of 2013-11-19 13:06:21 -0800:<br>
> > On 11/20/2013 09:50 AM, Clint Byrum wrote:<br>
> > > Excerpts from Steve Baker's message of 2013-11-18 12:52:04
-0800:<br>
> > >> Regarding apply_config/remove_config, if a SoftwareApplier
resource is<br>
> > >> deleted it should trigger any remove_config and wait
for the server to<br>
> > >> acknowledge when that is complete. This allows for any<br>
> > >> evacuation/deregistering workloads to be executed.<br>
> > >><br>
> > > I'm a little worried about the road that leads us down.
Most configuration<br>
> > > software defines forward progress only. Meaning, if you
want something<br>
> > > not there, you don't remove it from your assertions, you
assert that it<br>
> > > is not there.</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br><tt><font size=2><br>
> > > ...<br>
> > A specific use-case I'm trying to address here is tripleo doing
an<br>
> > update-replace on a nova compute node. The remove_config contains
the<br>
> > workload to evacuate VMs and signal heat when the node is ready
to be<br>
> > shut down. This is more involved than just "uninstall the
things".<br>
> > <br>
> > Could you outline in some more detail how you think this could
be done?<br>
> > <br>
> <br>
> So for that we would not remove the software configuration for the<br>
> nova-compute, we would assert that the machine needs vms evacuated.<br>
> We want evacuation to be something we explicitly do, not a side effect<br>
> of deleting things.</font></tt>
<br>
<br><tt><font size=2>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?</font></tt>
<br>
<br><tt><font size=2>> Perhaps having delete hooks for starting delete<br>
> work-flows is right, but it set off a red flag for me so I want to
make<br>
> sure we think it through.<br>
> <br>
> Also IIRC, evacuation is not necessarily an in-instance thing. It
looks<br>
> more like the weird thing we've been talking about lately which is<br>
> "how do we orchestrate tenant API's":<br>
> <br>
> </font></tt><a href="https://etherpad.openstack.org/p/orchestrate-tenant-apis"><tt><font size=2>https://etherpad.openstack.org/p/orchestrate-tenant-apis</font></tt></a><tt><font size=2><br>
</font></tt>
<br><tt><font size=2>This looks promising to me.</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>