Open Stack

<inline responses>

On 10/14/2014 01:13 PM, Thomas Spatzier wrote:
> 
> 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 ...).

It would be simple enough to make an RPM metapackage that just installs
the deps. The definition of self-contained I'm using here is "one
install command" and not "has its own vendored python and every module".

> 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).

I like this option much better, actually. Idoubt many deployers would
have complaints since cloud-init is pretty much standard. The downside
here is that it wouldn't be all that feasible to include bootstrap
scripts for every platform.

Maybe it would be enough to have the ability to bootstrap one or two
popular distros (Ubuntu, Fedora, Cent, etc) and accept patches for other
platforms.

> 
> Another issue that comes to mind: what about operating systems not
> supported by diskimage-builder (Windows), or other hypervisor platforms?
> 
> Any, not really suggestions from my side but more observations and
> thoughts. I wanted to share those and raise some discussion on possible
> options.
> 
> Regards,
> Thomas
> 
> [1]
> https://github.com/openstack/heat-templates/blob/master/hot/software-config/elements/README.rst
> [2]
> https://github.com/openstack/heat-templates/tree/master/hot/software-config/example-templates/cirros-example
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.