On Fri, Feb 06, 2015 at 05:29:33PM -0500, Solly Ross wrote: > Hi, > > I would like to request a non-priority feature freeze exception for the > "Use libvirt storage pools" blueprint [1]. > > The blueprint introduces a new image backed type that uses libvirt storage > pools, > and is designed to supercede several of the existing image backends for Nova. > Using libvirt storage pools simplifies both the maintenance of existing code > and the introduction of future storage pool types (since we can support > any libvirt storage pool format that supports the createXMLFrom API call). > It also paves the way for potentially using the storage pool API to assist > with SSH-less migration of disks (not part of this blueprint). > The blueprint also provides a way to migrate disks using legacy backends > to the new backend on cold migrations/resizes, reboots (soft and hard), > and live block migrations. > > The code [2] is up and working, and is split into (hopefully) manageable > chunks. > > Best Regards, > Solly Ross > > [1] > http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/use-libvirt-storage-pools.html > [2] https://review.openstack.org/#/c/152348/ and onward > > P.S. I would really like to get this in, since this would be the second time > that > this has been deferred, and took a good bit of manual rebasing to create the > Kilo > version from the Juno version.
Much as I'd like to see this feature in Nova, my recommendation is to reject this FFE. The image cache management code in particular has been a long term source of bugs and unexpected behaviour. While I think this series improves the code in question, the potential for causing regressions is none the less very high. An overhall of this area of code is really something that needs to get merged very early in a dev cycle (ie Kilo-1, or the start of Kilo-2) in order to allow enough opportunity to stablise it. The first posting for Kilo was only done on Jan 21, before that the previous update was Sept 7. I'm afraid this work was just far too late in Kilo to stand a reasonable chance of merging in Kilo given how complex the code in this area is. Regards, 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 Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
