[openstack-dev] Blueprint for Nova native image building

Monty Taylor mordred at inaugust.com
Tue Aug 6 19:02:45 UTC 2013

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.  :-)
>> 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.
> 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?

More information about the OpenStack-dev mailing list