<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/21/2013 10:46 AM, Mike Spreitzer
wrote:<br>
</div>
<blockquote
cite="mid:OF6198B1DD.E6AA0D6B-ON85257C29.0076E9B7-85257C29.00779B42@us.ibm.com"
type="cite"><tt><font size="2">Clint Byrum
<a class="moz-txt-link-rfc2396E" href="mailto:clint@fewbar.com"><clint@fewbar.com></a> wrote on 11/19/2013
04:28:31 PM:<br>
> From: Clint Byrum <a class="moz-txt-link-rfc2396E" href="mailto:clint@fewbar.com"><clint@fewbar.com></a></font></tt>
<br>
<tt><font size="2">> To: openstack-dev
<a class="moz-txt-link-rfc2396E" href="mailto:openstack-dev@lists.openstack.org"><openstack-dev@lists.openstack.org></a>,
</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>
</font></tt></blockquote>
<tt><font size="2">As I'm currently proposing, here are some stack
update scenarios:<br>
* update results in modified software config, apply_config will
be executed again on the affected server<br>
* update results in a server that requires replacement. This
results in:<br>
* execute the remove_config workload on that server. The
SoftwareApplier resource remains in DELETE_IN_PROGRESS until
signalled that remove_config is complete<br>
* delete the server<br>
* create the replacement server<br>
* execute apply_config on that server...<br>
</font></tt>
<blockquote
cite="mid:OF6198B1DD.E6AA0D6B-ON85257C29.0076E9B7-85257C29.00779B42@us.ibm.com"
type="cite"><tt><font size="2">
> > > ...<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>
</blockquote>
Nobody is being forced. remove_config is entirely optional and only
exists for the more complex scenarios requiring
evacuation/deregistering.<br>
<br>
If remove_config is not specified, the SoftwareApplier should
probably go straight to DELETE_COMPLETE without waiting for any
signal.<br>
<br>
<blockquote
cite="mid:OF6198B1DD.E6AA0D6B-ON85257C29.0076E9B7-85257C29.00779B42@us.ibm.com"
type="cite"><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 moz-do-not-send="true"
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>
</blockquote>
It looks like these might be represented as SoftwareConfigs<br>
</body>
</html>