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://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
