Open Stack

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 <berrange at redhat.com
> <mailto:berrange at 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 at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>