<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/16/2013 02:21 PM, Mike Spreitzer
wrote:<br>
</div>
<blockquote
cite="mid:OF49CD5501.C758FC78-ON85257C06.00060F39-85257C06.00076F83@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>
> From: Steve Baker <a class="moz-txt-link-rfc2396E" href="mailto:sbaker@redhat.com"><sbaker@redhat.com></a></font></tt>
<br>
<tt><font size="2">> To: <a class="moz-txt-link-abbreviated" href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>, </font></tt>
<br>
<tt><font size="2">> Date: 10/15/2013 06:51 PM</font></tt>
<br>
<tt><font size="2">> Subject: [openstack-dev] [Heat] HOT
Software
configuration proposal</font></tt>
<br>
<tt><font size="2">> <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>
<br>
<br>
<tt><font size="2">In that proposal, each component can use a
different
configuration management tool.</font></tt>
<br>
<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>
</font></tt>
<br>
<tt><font size="2">In this proposal, I get the idea that it is
intended
that each Compute instance run only one configuration
management tool.
At least, most of the text discusses the support (e.g., the
idea
that each CM tool supplies userdata to bootstrap itself) in
terms appropriate
for a single CM tool per instance; also, there is no
discussion of combining
userdata from several CM tools.</font></tt>
<br>
<br>
</blockquote>
I think users should be told that it is possible but foolhardy to
mix CM tools in a single server. The exception to this *might* be
allowing one Heat::CloudInit (or Heat::SoftwareConfig) component to
install the other CM tool on a pristine image before running the
other components that use that tool.<br>
<br>
Initially I thought that each component type should be able to
ensure that its CM tool is installed before invoking that tool. The
realities of doing this the right way all the time are difficult
though[1] so I've backed away from this for now. It can always be
added as an enhancement later. In the meantime users are free to
build images that have all required prerequisites, or install them
with a Heat::CloudInit (or Heat::SoftwareConfig) component on boot.<br>
<br>
<blockquote
cite="mid:OF49CD5501.C758FC78-ON85257C06.00060F39-85257C06.00076F83@us.ibm.com"
type="cite"><tt><font size="2">I agree with the separation of
concerns issues that
have been raised. I think all this software config stuff can
be handled
by a pre-processor that takes an extended template in and
outputs a plain
template that can be consumed by today's heat engine (no
extension to the
heat engine necessary).</font></tt>
<br>
<tt><font size="2"></font></tt><br>
</blockquote>
A stated goal of the heat template format is that it be fit-for-use
by humans. Pre-processing is a perfectly valid technique for other
services that use heat and we encourage that. However if the
pre-processing is to work around usability issues in the template
format I would rather focus on fixing those issues.<br>
<br>
[1] Currently the most reliable way of installing heat-cfntools on
any arbitrary pristine image is in a venv<br>
</body>
</html>