Open Stack

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.