Open Stack

Hi Robert,

On Thu, 2013-04-04 at 12:27 +1300, Robert Collins wrote:
> On 4 April 2013 11:10, Ian McLeod <imcleod at redhat.com> wrote:
> > We've put together a simple proof of concept of driving native operating
> > system installers using Nova:
> >
> > https://github.com/redhat-openstack/image-building-poc
> >
> > The python CLI tool in this repo, when combined with the example install
> > scripts, can build both glance-backed and cinder-backed JEOS images for
> > the following operating systems entirely inside of Nova:
> >
> > Fedora 17, 18
> > Ubuntu 10.04, 12.04, 12.10
> > RHEL 5.9, 6.4
> >
> > These builds can be done using network install sources and, in some
> > limited cases, DVD/ISO install sources.  Full details can be found in
> > the README.md file on github.
> >
> > Some background discussion about this approach from earlier this year
> > can be found here:
> >
> > https://wiki.openstack.org/wiki/NovaImageBuilding
> >
> > The code is a bit rough around the edges but we believe the approach has
> > promise and can form the basis for a proper image building service
> > native to OpenStack.
> 
> It's cool you've done this - I think such a general solution is
> necessary, particularly for folk running systems like Windows.
> 
> > I'd be grateful if anyone who's interested in the problem of image
> > building could have a look at this, give it a try and share
> > thoughts/feedback.
> 
> We've been working on a much lighter weight solution - using as you
> note chroots - because we need something that can build images *fast*.
> TripleO wants to deploy Openstack as part of the CI pipeline, so even
> short (multiple second) delays add up rapidly as you starting
> generating images inline in the landing process.
> https://github.com/stackforge/diskimage-builder/ is the project we put
> together.
> 
> The focus we have is building images which can be used to deploy
> openstack, so we have a hard requirement to not depend on openstack
> itself - but having an API that can drive building of images (by
> spinning up a machine on the back end) would be useful, to make custom
> images easier for folk on limited hardware etc.
> 
> Perhaps we can collaborate on having a common API for creating images,
> with multiple backends - one oz for super generality, and one
> diskimage-builder for fast creation?

An API with multiple backends is certainly very openstack-esque :-)

I had seen diskimage-builder and a Nova based image building service as
both being separately excellent for their specific use cases:

  - diskimage-builder - the user building the image is an OpenStack 
    admin so is "close" to the image store

  - Nova based image building - a facility exposed to remote user of the
    OpenStack clouds and allows them to build images in the cloud rather
    than building locally and uploading. Also, it means that the user
    gets build for compute, network and storage used during the image
    build itself.

Now, as you say, you could take any image building tool like
diskimage-builder and have a service which launches a Nova VM with an
image containing the image builder tool, passes through details of what
you want built, the user's glance/cinder credentials ... and it would
behave pretty similarly. I'm guessing an API abstraction that works for
both modes is doable too.

I'm a little dubious that the speed vs generality tradeoff is worth the
effort of having multiple drivers (e.g. does the API allow a user to
choose which driver to use, or does the admin configure it) but perhaps
it would be a nice way of bringing different image building ideas
together in the one project.

Cheers,
Mark.