[openstack-dev] [Heat] image requirements for Heat software config

Steve Baker sbaker at redhat.com
Tue Oct 14 22:24:17 UTC 2014


On 15/10/14 10:38, Clint Byrum wrote:
> Excerpts from Thomas Spatzier's message of 2014-10-14 10:13:27 -0700:
>> 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.
>>
> I don't really understand why a "consolidated release process across
> all" would be desired or needed.
>
> #3 is pretty odd. You're pulling in templates from the examples repo?
heat-templates is where our hook elements live:

[1]
https://github.com/openstack/heat-templates/blob/master/hot/software-config/elements/README.rst


> For #4-#6, those are all on pypi and released on a regular basis. Build
> yourself a bandersnatch mirror and you'll have locally controlled access
> to them which should eliminate any reliability issues.
>
>> 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).
> The agent problem is one reason I've been drifting away from Heat
> for software configuration, and toward Ansible. Mind you, I wrote
> os-collect-config to have as few dependencies as possible as one attempt
> around this problem. Still it isn't capable enough to do the job on its
> own, so you end up needing os-apply-config and then os-refresh-config
> to tie the two together.
For heat's requirements, os-refresh-config or os-apply-config is 
overkill to go from occ to the config hooks, but they're tiny and useful 
in their own right so I'm OK with requiring them.



More information about the OpenStack-dev mailing list