[openstack-dev] Blueprint for Nova native image building

Russell Bryant rbryant at redhat.com
Wed Aug 7 14:34:57 UTC 2013

On 08/06/2013 06:06 PM, Ian McLeod wrote:
> On Tue, 2013-08-06 at 16:02 -0300, Monty Taylor wrote:
> 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.

Can you write up some more detail on this point?

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

If we were to service-ify this, it would be interesting to look into
using Ceilometer for monitoring.

>>>> 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?
> Other than the Xen issue above, I'm not sure there's anything that
> simply won't work at all, though there are things that perhaps won't
> scale as well or won't run as quickly.

Why would it be slower?

How about scale?  Just the increased API load?  I wouldn't expect this
to be something done frequently.  It's more API calls, but removes a
long running task from inside nova (longer than anything else that
exists in nova today).

>>>> If it doesn't end up on the server side, it could potentially be
>>>> implemented as an extension to novaclient.
>>> Also, whatever we end up with, I'd like to see it hypervisor agnostic as
>>> much as possible.  I just came across this xen specific patch:
>>> https://review.openstack.org/#/c/38650/
>> Yes to everything Russel said. I'd like to see the tool be standalone.
>> Then, if there is a desire to provide the ability to run it via an api,
>> the tool could be consumed (similar discussions have happened around
>> putting diskimage-builder behind a service as well)
>> That said - if we did service-ify the tool, wouldn't glance be a more
>> appropriate place for that sort of thing?
> Possibly, though the proof of concept (and we hope our proposed
> nova-based re-implementation) can build both glance images and cinder
> volume backed images.

I like this idea (glance seeming to make more sense conceptually).

It seems like the main sticking point is whether or not it can be made
to work for all (or most) hypervisors from outside of nova.  Can we dig
into this point a bit deeper?

Russell Bryant

More information about the OpenStack-dev mailing list