<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 10/22/2013 08:45 AM, Mike Spreitzer
wrote:<br>
</div>
<blockquote
cite="mid:OFCB0565BD.A1A8471B-ON85257C0B.006BA131-85257C0B.006C8A57@us.ibm.com"
type="cite"><tt><font size="2">Steve Baker
<a class="moz-txt-link-rfc2396E" href="mailto:sbaker@redhat.com"><sbaker@redhat.com></a> wrote on 10/15/2013
06:48:53 PM:<br>
<br>
> I've just written some proposals to address Heat's HOT
software <br>
> configuration needs, and I'd like to use this thread to
get some feedback:<br>
> </font></tt><a moz-do-not-send="true"
href="https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config"><tt><font
size="2">https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config</font></tt></a><tt><font
size="2"><br>
> </font></tt><a moz-do-not-send="true"
href="https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-bootstrap-config"><tt><font
size="2">https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-bootstrap-config</font></tt></a><tt><font
size="2"><br>
> <br>
> Please read the proposals and reply to the list with any
comments
or<br>
> suggestions.<br>
</font></tt>
<br>
<tt><font size="2">Can you confirm whether I have got the big
picture
right? I think some of my earlier remarks were mistaken.</font></tt>
<br>
<br>
<tt><font size="2">You propose to introduce the concept of
component
and recognize software configuration as a matter of invoking
components
--- with a DAG of data dependencies among the component
invocations. While
this is similar to what today's heat engine does for
resources, you do
NOT propose that the heat engine will get in the business of
invoking components.
Rather: each VM will run a series of component invocations,
and in-VM
mechanisms will handle the cross-component synchronization and
data communication.
</font></tt></blockquote>
<tt><font size="2">This is basically correct, except that in-VM
mechanisms won't know much about </font></tt><tt><font size="2">
cross-component synchronization and data communication. They
will just execute whatever components are available to be
executed, and report back values to heat-engine by signalling to
waitconditions.<br>
</font></tt>
<blockquote
cite="mid:OFCB0565BD.A1A8471B-ON85257C0B.006BA131-85257C0B.006C8A57@us.ibm.com"
type="cite"><tt><font size="2"> You propose to add a bit of
sugaring for the wait condition&handle
mechanism, and the heat engine will do the de-sugaring. </font></tt></blockquote>
<tt><font size="2">Yes, I think improvements can be made on what I
proposed, such as every component signalling when it is
complete, and optionally including a return value in that
signal.</font></tt><br>
<blockquote
cite="mid:OFCB0565BD.A1A8471B-ON85257C0B.006BA131-85257C0B.006C8A57@us.ibm.com"
type="cite"><tt><font size="2"> Each component
is written in one of a few supported configuration management
(CM) frameworks,
and essentially all component invocations on a given VM invoke
components
of the same CM framework (with possible exceptions for one or
two really
basic ones).</font></tt></blockquote>
<tt><font size="2">Rather than being limited to a few supported CM
tools, I like the idea of some kind of provider mechanism so
that users or heat admins can add support for new CM tools. This
implies that it needs to be possible to add a component type
without requiring custom python that runs on heat engine. </font></tt><br>
<blockquote
cite="mid:OFCB0565BD.A1A8471B-ON85257C0B.006BA131-85257C0B.006C8A57@us.ibm.com"
type="cite"><tt><font size="2">The heat engine gains the
additional responsibility
of making sure that the appropriate CM framework(s) is(are)
bootstrapped
in each VM.</font></tt></blockquote>
<tt><font size="2">Maybe. Or it might be up to the user to invoke
images that already have the CM tools installed, or the user can
provide a custom component provider which installs the tool in
the way that they want.</font></tt><br>
<br>
<tt><font size="2">As for the </font></tt><tt><font size="2">cross-component
synchronization and data communication question, at this stage
I'm not comfortable with bringing something like zookeeper into
the mix for a general solution for inter-component
communication. If heat engine handles resource dependencies and
zookeeper handles software configuration dependencies this would
result in the state of the stack being split between two
different co-ordination mechanisms.<br>
<br>
We've put quite some effort into heat engine to co-ordinate
resource dependencies. Wait conditions are currently cumbersome
to use, but by exposing software configuration state in terms of
resource dependencies they do enable heat engine to be central
source of state for the entire stack, including progress of
software config.<br>
<br>
If wait conditions can become palatable to use (or completely
transparent) then to me that addresses the main concerns about
using them in the short term. Longer term I'd consider something
like Marconi to replace metadata polling and wait condition
signalling but it is too early to be having that conversation.<br>
</font></tt>
</body>
</html>