<div dir="ltr">There is a current proposal in glance that is receiving development attention towards "importing" images asynchronously from a variety of sources. The import feature is plugin-based, so it would be easy to add on the ability and a plugin to do something like importing base os installs.<div>
<br></div><div>The blueprint is <a href="https://blueprints.launchpad.net/glance/+spec/new-upload-workflow">https://blueprints.launchpad.net/glance/+spec/new-upload-workflow</a>. It is currently targeted for Havana-3 (but is probably the first blueprint on the chopping block due to other dependencies that have not yet landed).</div>
<div><br></div><div>I think this approach probably makes more sense than putting the code directly into Nova. But overall, I'm somewhat in favor of keeping this feature out of core OpenStack projects for now. It feels niche enough that it could live as its own project without burdening its users--most folks who build base images are probably operations anyway and can deploy stuff. And I think there are a number of other tools perhaps that make it easier for the smallest shops to build base images (?)</div>
<div><br></div><div>I don't buy the argument about it being a lot more work to implement this feature outside of OpenStack. Not that the argument is false, but the concern seems minor compared to the cost of weighing down core with yet another feature. From where I'm sitting, OpenStack is still in the "too many features coming too fast" regime and architecture hasn't caught up. So putting on the breaks wherever possible seems like the wisest course.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 8, 2013 at 7:33 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Aug 08, 2013 at 09:28:51AM -0500, Ian McLeod wrote:<br>
> On Wed, 2013-08-07 at 12:05 -0400, Russell Bryant wrote:<br>
> > On 08/07/2013 10:46 AM, Daniel P. Berrange wrote:<br>
> > > On Tue, Aug 06, 2013 at 12:20:00PM -0400, Russell Bryant wrote:<br>
> > >> On 08/06/2013 11:53 AM, Ian Mcleod wrote:<br>
> > >>> Hello,<br>
> > >>><br>
> > >>> A blueprint has been registered regarding API additions to Nova to<br>
> > >>> enable the creation of base images from external OS install sources.<br>
> > >>> This provides a way to build images from scratch via native OS installer<br>
> > >>> tools using only the resources provided through Nova.  These images can<br>
> > >>> then be further customized by other tools that expect an existing image<br>
> > >>> as an input, such as disk image builder.<br>
> > >>><br>
> > >>> Blueprint -<br>
> > >>> <a href="https://blueprints.launchpad.net/nova/+spec/base-image-creation" target="_blank">https://blueprints.launchpad.net/nova/+spec/base-image-creation</a><br>
> > >>><br>
> > >>> Specification - <a href="https://wiki.openstack.org/wiki/NovaImageCreationAPI" target="_blank">https://wiki.openstack.org/wiki/NovaImageCreationAPI</a><br>
> > >>><br>
> > >>> If this is a topic that interests you, please have a look (the spec is<br>
> > >>> not very long) and join the conversation.<br>
> > >>><br>
> > >>> Please note that this blueprint follows on from proof of concept work<br>
> > >>> for native image building discussed on this list in April:<br>
> > >>><br>
> > >>> <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-April/007157.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-April/007157.html</a><br>
> > >><br>
> > >> Thanks of the update on this work.<br>
> > >><br>
> > >> I see that your proof of concept shows how this can work as a tool<br>
> > >> outside of Nova:<br>
> > >><br>
> > >> <a href="https://github.com/redhat-openstack/image-building-poc" target="_blank">https://github.com/redhat-openstack/image-building-poc</a><br>
> > >><br>
> > >> So, my biggest question is whether or not it makes sense for this to be<br>
> > >> a Nova feature or not.  If something can be implemented as a consumer of<br>
> > >> Nova, my default answer is that it should stay outside of nova until I<br>
> > >> am convinced otherwise.  :-)<br>
> > >><br>
> > >> It sounds like this is mostly an extension to nova that implements a<br>
> > >> series of operations that can be done just as well outside of Nova.  Are<br>
> > >> there enhancements you are making or scenarios that won't work at all<br>
> > >> unless it lives inside of Nova?<br>
> > >><br>
> > >> If it doesn't end up on the server side, it could potentially be<br>
> > >> implemented as an extension to novaclient.<br>
> > ><br>
> > > I think the key thing is that want to make sure we don't have all<br>
> > > clients apps having to re-invent the wheel. The way the proof of<br>
> > > concept was done as a standalone tool, would entail such wheel<br>
> > > re-invention by any frontend to Nova like the 'nova' cli and<br>
> > > Horizon dashboard. Possibly you could mitigate that if you could<br>
> > > actually put all the smarts in the python-novaclient library API<br>
> > > so it was shared by all frontend apps.<br>
> ><br>
> > Yeah, I was thinking python-novaclient.  The 'nova' command line tool is<br>
> > just a wrapper around the library portion.<br>
> ><br>
> > > IIUC, though there is some state information that it is desirable<br>
> > > to maintain while the images are being built. You'd probably<br>
> > > such state visible to all clients talking to the same nova instance,<br>
> > > not hidden away in the client side where its only visible to that<br>
> > > single frontend instance.<br>
> ><br>
> > That's an interesting point.  Do we care about having an image build<br>
> > executing by the command line to show up in the UI as an image build?<br>
> > Right now it's just going to be another nova instance.  We have to do it<br>
> > on the server side to do any better.  I'm not even sure it could<br>
> > integrate well with Horizon doing it in python-novaclient.  I don't<br>
> > think you could start another session and see the operation in progress.<br>
><br>
> Perhaps it's worth revisiting the basic question:<br>
><br>
> Is scratch image building (as distinct from run time customization) a<br>
> task that benefits from being exposed as a distinct activity available<br>
> to a typical Horizon user or as structured resource available to other<br>
> services via REST?<br>
><br>
> The blueprint assumes the answer is yes.<br>
><br>
> But, is scratch image building in fact low level and infrequent enough<br>
> to live happily as a standalone tool?  (Oz for Nova, if you will.)<br>
<br>
</div></div>I don't think frequency of usage is the right question to evaluate<br>
this really. Even if it is only used by a small set of users,<br>
if those users are using Horizon for their work, IMHO, they will<br>
rightly expect image building to fit into Horizon, not have to go<br>
to a separate standalone tool for the job.<br>
<div class="im HOEnZb"><br>
<br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a>      -o-    <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a>              -o-             <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a>       -o-         <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a>       -o-       <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>