I believe this is where the thread stopped a couple weeks ago. I was just curious what has happened since. How did you interpret all of the feedback given, and what direction have you decided to take next?
Thanks, -- Russell Bryant On 08/08/2013 12:42 PM, Mark Washenberger wrote: > 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. > > The blueprint > is https://blueprints.launchpad.net/glance/+spec/new-upload-workflow. 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). > > 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 (?) > > 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. > > > On Thu, Aug 8, 2013 at 7:33 AM, Daniel P. Berrange <berra...@redhat.com > <mailto:berra...@redhat.com>> wrote: > > On Thu, Aug 08, 2013 at 09:28:51AM -0500, Ian McLeod wrote: > > On Wed, 2013-08-07 at 12:05 -0400, Russell Bryant wrote: > > > On 08/07/2013 10:46 AM, Daniel P. Berrange wrote: > > > > On Tue, Aug 06, 2013 at 12:20:00PM -0400, 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. > > > > > > > > I think the key thing is that want to make sure we don't have all > > > > clients apps having to re-invent the wheel. The way the proof of > > > > concept was done as a standalone tool, would entail such wheel > > > > re-invention by any frontend to Nova like the 'nova' cli and > > > > Horizon dashboard. Possibly you could mitigate that if you could > > > > actually put all the smarts in the python-novaclient library API > > > > so it was shared by all frontend apps. > > > > > > Yeah, I was thinking python-novaclient. The 'nova' command line > tool is > > > just a wrapper around the library portion. > > > > > > > IIUC, though there is some state information that it is desirable > > > > to maintain while the images are being built. You'd probably > > > > such state visible to all clients talking to the same nova > instance, > > > > not hidden away in the client side where its only visible to that > > > > single frontend instance. > > > > > > That's an interesting point. Do we care about having an image build > > > executing by the command line to show up in the UI as an image > build? > > > Right now it's just going to be another nova instance. We have > to do it > > > on the server side to do any better. I'm not even sure it could > > > integrate well with Horizon doing it in python-novaclient. I don't > > > think you could start another session and see the operation in > progress. > > > > Perhaps it's worth revisiting the basic question: > > > > Is scratch image building (as distinct from run time customization) a > > task that benefits from being exposed as a distinct activity available > > to a typical Horizon user or as structured resource available to other > > services via REST? > > > > The blueprint assumes the answer is yes. > > > > But, is scratch image building in fact low level and infrequent enough > > to live happily as a standalone tool? (Oz for Nova, if you will.) > > I don't think frequency of usage is the right question to evaluate > this really. Even if it is only used by a small set of users, > if those users are using Horizon for their work, IMHO, they will > rightly expect image building to fit into Horizon, not have to go > to a separate standalone tool for the job. > > > Daniel > -- > |: http://berrange.com -o- > http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- > http://virt-manager.org :| > |: http://autobuild.org -o- > http://search.cpan.org/~danberr/ <http://search.cpan.org/%7Edanberr/> :| > |: http://entangle-photo.org -o- > http://live.gnome.org/gtk-vnc :| > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev