Open Stack

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.

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

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

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