Open Stack

Excerpts from Clint Byrum's message on 14/10/2014 23:38:46:
<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.
> >
>
> I don't really understand why a "consolidated release process across
> all" would be desired or needed.

Well, all pieces have to fit together so everything work. I had many
situations where I used the currently up-to-date version of each piece but
something just did not work. Then I found that some patch was in review on
any of those, so trying a few days later worked.
I would be good for users to have one verified package of everything
instead of going thru a trial and error process.
Maybe this is going to improve in the future, since so far or until
recently a lot of software config was still work in progress. But up to
now, the image building has been a challenge at some time.

>
> #3 is pretty odd. You're pulling in templates from the examples repo?

We have to pull in the image elements and hooks for software config from
there.

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

So switching from git repo based installed as described in [1] to pypi
based installs, where I can specify a version number would help?
Then what we would still need is a set of version for each package that are
verified to work together (my previous point).

>
> > 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.
>
> Ansible requires sshd, and python, with a strong recommendation for
> sudo. These are all things that pretty much every Linux distribution is
> going to have available.

Interesting, I have to investigate this. Thanks for the hint.

>
> >
> > Another issue that comes to mind: what about operating systems not
> > supported by diskimage-builder (Windows), or other hypervisor
platforms?
> >
>
> There is a windows-diskimage-builder:
>
> https://git.openstack.org/cgit/stackforge/windows-diskimage-builder

Good to know; I wasn't aware of it. Thanks!

>
> diskimage-builder can produce raw images, so that should be convertible
> to pretty much any other hypervisor's preferred disk format.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>