Open Stack

On Tue, Aug 06, 2013 at 12:20:00PM -0400, Russell Bryant wrote:
> On 08/06/2013 11:53 AM, Ian Mcleod wrote:
> > Hello,
> > 
> > A blueprint has been registered regarding API additions to Nova to
> > enable the creation of base images from external OS install sources.
> > This provides a way to build images from scratch via native OS installer
> > tools using only the resources provided through Nova.  These images can
> > then be further customized by other tools that expect an existing image
> > as an input, such as disk image builder.
> > 
> > Blueprint -
> > https://blueprints.launchpad.net/nova/+spec/base-image-creation
> > 
> > Specification - https://wiki.openstack.org/wiki/NovaImageCreationAPI
> > 
> > If this is a topic that interests you, please have a look (the spec is
> > not very long) and join the conversation.
> > 
> > Please note that this blueprint follows on from proof of concept work
> > for native image building discussed on this list in April:
> > 
> > http://lists.openstack.org/pipermail/openstack-dev/2013-April/007157.html
> 
> Thanks of the update on this work.
> 
> I see that your proof of concept shows how this can work as a tool
> outside of Nova:
> 
> https://github.com/redhat-openstack/image-building-poc
> 
> So, my biggest question is whether or not it makes sense for this to be
> a Nova feature or not.  If something can be implemented as a consumer of
> Nova, my default answer is that it should stay outside of nova until I
> am convinced otherwise.  :-)
> 
> It sounds like this is mostly an extension to nova that implements a
> series of operations that can be done just as well outside of Nova.  Are
> there enhancements you are making or scenarios that won't work at all
> unless it lives inside of Nova?
> 
> If it doesn't end up on the server side, it could potentially be
> implemented as an extension to novaclient.

I think the key thing is that want to make sure we don't have all
clients apps having to re-invent the wheel. The way the proof of
concept was done as a standalone tool, would entail such wheel
re-invention by any frontend to Nova like the 'nova' cli and
Horizon dashboard. Possibly you could mitigate that if you could
actually put all the smarts in the python-novaclient library API
so it was shared by all frontend apps.

IIUC, though there is some state information that it is desirable
to maintain while the images are being built. You'd probably
such state visible to all clients talking to the same nova instance,
not hidden away in the client side where its only visible to that
single frontend instance.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|