Open Stack

Excerpts from Steve Baker's message on 14/10/2014 23:52:41:

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

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

Yeah, I understand that the current situation is probably there because we
are so close to the point where the features get developed. So hopefully
this will improve and stabilize in the future.

>
> 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, 55-heat-config, the actual desired
> config hook...)

Thanks for the pointer. I'll have a look. I think if we can put as little
requirements on the base image and do as much as possible at boot, that
would be good. If help is needed for getting this done for other distros
(and for Windows) we can certainly work on this. We just have to agree and
be convinced that this is the right path.

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

I'll have a look at all the pointers. Agree that this is extremely useful.

BTW: the unit testing work you started on the software config hooks will
definitely help as well!

>
> Another issue that comes to mind: what about operating systems not
> supported by diskimage-builder (Windows), or other hypervisor platforms?

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

Yes, I've seen those templates. As long as there is an image that work with
them, this is great. I have to look closer into the Windows things.

>
> Any, not really suggestions from my side but more observations and
> thoughts. I wanted to share those and raise some discussion on possible
> options.

> Thanks Thomas, that was useful.
>
> cheers

>
>
> [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

> [3] https://review.openstack.org/#/c/119282/1/hot/software-config/
> example-templates/pristine-image/install_config_agent.sh
> [4] http://git.openstack.org/cgit/openstack/openstack-manuals/tree/
> doc/hot-guide/source/software_deployment.rst
> [5] https://review.openstack.org/#/c/127109/
> [6]
http://git.openstack.org/cgit/openstack/heat-templates/tree/hot/Windows
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev