<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 15/10/14 06:13, Thomas Spatzier
wrote:<br>
</div>
<blockquote
cite="mid:OF3B88B433.E9585BEF-ONC1257D70.00441CE8-C1257D71.005E9D84@de.ibm.com"
type="cite">
<pre wrap="">
Hi all,
I have been experimenting a lot with Heat software config to check out
what works today, and to think about potential next steps.
I've also worked on an internal project where we are leveraging software
config as of the Icehouse release.
I think what we can do now from a user's perspective in a HOT template is
really nice and resonates well also with customers I've talked to.
One of the points where we are constantly having issues, and also got some
push back from customers, are the requirements on the in-instance tools and
the process of building base images.
One observation is that building a base image with all the right stuff
inside sometimes is a brittle process; the other point is that a lot of
customers do not like a lot of requirements on their base images. They want
to maintain one set of corporate base images, with as little modification
on top as possible.
Regarding the process of building base images, the currently documented way
[1] of using diskimage-builder turns out to be a bit unstable sometimes.
Not because diskimage-builder is unstable, but probably because it pulls in
components from a couple of sources:
#1 we have a dependency on implementation of the Heat engine of course (So
this is not pulled in to the image building process, but the dependency is
there)
#2 we depend on features in python-heatclient (and other python-* clients)
#3 we pull in implementation from the heat-templates repo
#4 we depend on tripleo-image-elements
#5 we depend on os-collect-config, os-refresh-config and os-apply-config
#6 we depend on diskimage-builder itself
Heat itself and python-heatclient are reasonably well in synch because
there is a release process for both, so we can tell users with some
certainty that a feature will work with release X of OpenStack and Heat and
version x.z.y of python-heatclient. For the other 4 sources, success
sometimes depends on the time of day when you try to build an image
(depending on what changes are currently included in each repo). So
basically there does not seem to be a consolidated release process across
all that is currently needed for software config.
The ideal solution would be to have one self-contained package that is easy
to install on various distributions (an rpm, deb, MSI ...).
Secondly, it would be ideal to not have to bake additional things into the
image but doing bootstrapping during instance creation based on an existing
cloud-init enabled image. For that we would have to strip requirements down
to a bare minimum required for software config. One thing that comes to my
mind is the cirros software config example [2] that Steven Hardy created.
It is admittedly no up to what one could do with an image built according
to [1] but on the other hand is really slick, whereas [1] installs a whole
set of things into the image (some of which do not really seem to be needed
for software config).
</pre>
</blockquote>
<br>
Building an image from git repos was the best chance of having a
single set of instructions which works for most cases, since the
tools were not packaged for debian derived distros. This seems to be
improving though; the whole build stack is now packaged for Debian
Unstable, Testing and also Ubuntu Utopic (which isn't released yet).
Another option is switching the default instructions to installing
from pip rather than git, but that still gets into distro-specific
quirks which complicate the instructions. Until these packages are
on the recent releases of common distros then we'll be stuck in this
slightly awkward situation.<br>
<br>
I wrote a cloud-init boot script to install the agents from packages
from a pristine Fedora 20 [3] and it seems like a reasonable
approach for when building a custom image isn't practical. Somebody
submitting the equivalent for Debian and Ubuntu would be most
welcome. We need to decide whether *everything* should be packaged
or if some things can be delivered by cloud-init on boot
(os-collect-config.conf template,
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
55-heat-config, the actual desired config hook...)<br>
<br>
I'm all for there being documentation for the different ways of
getting the agent and hooks onto a running server for a given
distro. I think the hot-guide would be the best place to do that,
and I've been making a start on that recently [4][5] (help
welcome!). The README in [1] should eventually refer to the
hot-guide once it is published so we're not maintaining multiple
build instructions.<br>
<br>
<blockquote
cite="mid:OF3B88B433.E9585BEF-ONC1257D70.00441CE8-C1257D71.005E9D84@de.ibm.com"
type="cite">
<pre wrap="">
Another issue that comes to mind: what about operating systems not
supported by diskimage-builder (Windows), or other hypervisor platforms?
</pre>
</blockquote>
The Cloudbase folk have contributed some useful cloudbase-init
templates this cycle [6], so that is a start. I think there is
interest in porting os-*-config to Windows as the way of enabling
deployment resources (help welcome!).<br>
<blockquote
cite="mid:OF3B88B433.E9585BEF-ONC1257D70.00441CE8-C1257D71.005E9D84@de.ibm.com"
type="cite">
<pre wrap="">
Any, not really suggestions from my side but more observations and
thoughts. I wanted to share those and raise some discussion on possible
options.
</pre>
</blockquote>
Thanks Thomas, that was useful.<br>
<br>
cheers<br>
<br>
<blockquote
cite="mid:OF3B88B433.E9585BEF-ONC1257D70.00441CE8-C1257D71.005E9D84@de.ibm.com"
type="cite">
<pre wrap="">
[1]
<a class="moz-txt-link-freetext" href="https://github.com/openstack/heat-templates/blob/master/hot/software-config/elements/README.rst">https://github.com/openstack/heat-templates/blob/master/hot/software-config/elements/README.rst</a>
[2]
<a class="moz-txt-link-freetext" href="https://github.com/openstack/heat-templates/tree/master/hot/software-config/example-templates/cirros-example">https://github.com/openstack/heat-templates/tree/master/hot/software-config/example-templates/cirros-example</a>
</pre>
</blockquote>
[3]
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/119282/1/hot/software-config/example-templates/pristine-image/install_config_agent.sh">https://review.openstack.org/#/c/119282/1/hot/software-config/example-templates/pristine-image/install_config_agent.sh</a><br>
[4]
<a class="moz-txt-link-freetext" href="http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/hot-guide/source/software_deployment.rst">http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/hot-guide/source/software_deployment.rst</a><br>
[5] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/127109/">https://review.openstack.org/#/c/127109/</a><br>
[6]
<a class="moz-txt-link-freetext" href="http://git.openstack.org/cgit/openstack/heat-templates/tree/hot/Windows">http://git.openstack.org/cgit/openstack/heat-templates/tree/hot/Windows</a><br>
<br>
</body>
</html>