Open Stack

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