Open Stack

Excerpts from Ian McLeod's message of 2013-08-06 15:06:34 -0700:
> On Tue, 2013-08-06 at 16:02 -0300, Monty Taylor wrote:
> > 
> > On 08/06/2013 03:46 PM, Russell Bryant wrote:
> > > On 08/06/2013 12:20 PM, 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.  :-)
> 
> The proof of concept approach is limited to full-virt hypervisors.  It's
> unclear to me if there's a way we can make this work for Xen-backed
> installs without the kind of lower level access to the virt environment
> that we'll get if we exist inside of Nova.
> 
> More generally, it's likely that we'll have more flexibility to behave
> in a sane/optimized manner based on backing hypervisor if the code is
> inside of Nova.  For example, we've talked about improving our detection
> of a failed install by monitoring disk IO.
> 

Flexibility can also be looked at as complexity. Complexity in Nova
is expensive in many ways. But just poking a few more holes into
Nova via the API would be a simple and effective way to manage that
complexity. Exposing some lower level things would get you the needed
pieces for your iPXE setup, and Monitoring disk IO is what ceilometer
does. Is there something else non-obvious that you need inside Nova?

If you had an API to get at the hypervisor bits you need, and the
capability to monitor the progress, then I think your service can just
run standalone and be another endpoint for users, with its own client.

Another option is to write this as a resource plugin for Heat, as its job
is to control multi-service operations. However, that will likely be an
unpopular option until Heat grows an imperative API for things like this.