Open Stack

On Wed, 2013-08-07 at 11:00 -0700, Clint Byrum wrote:
> 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 Ceilometer can provide the disk IO data, and the Nova API can be
expanded to allow direct specification of a kernel, ramdisk _and_ kernel
command line for Xen PV (and ideally, any other backing hypervisor that
supports direct boot), then we'd likely have what we need to do this
outside of Nova.

There may be some performance penalty that comes with adding an extra
"hop" when moving around kernels and ramdisks.  (I'm guessing the path
would become origin -> glance -> compute node versus, potentially,
origin directly to compute node.)

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

That's an interesting idea.

> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev