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
