Open Stack

Hi,

I would like to request a feature freeze exception for the first part of the
use-libvirt-storage-pools blueprint [1].

Overview
========

The patches in question [2] would entail adding support for libvirt storage pools,
but neither making them default nor adding in automatic transitioning [3] from the
legacy backends to the storage pool backends.  This would allow new deployments
and/or "adventurous" existing deployments to switch to libvirt storage pools,
while adding an extra release before the automated transitioning and switch
to default (as per the blueprint) is made.

Risk
====

While the risk is not negligible, it is relatively minor, since the major changes
are behind a configuration option ("[libvirt] use_storage_pools").  Additionally,
since the major changes are enabled by default [4], there is little danger of breakage
in existing deployments

Benefits
========

The plan according to the original blueprint was to enable automatic transitioning of
legacy backends to the new backend, and setting the storage pools to default to enabled.
However, this would likely not be a good idea for feature freeze, as things like that
can cause complicated and odd bugs (although we all hope our code has no bugs, it's more
or less inevitable that bugs pop up ;-)).

However, adding support for using the storage pool backend without enabling it by default
or adding in automatic transitioning in Juno would give an extra cycle to ensure that any
bugs get reported before the storage pool backend is made default.  Then, the rest of the
spec could proceed as planned, just moved up a relase (i.e. deprecate the legacy backends
in Kilo, and remove in L, assuming, of course, that the spec is re-approved).

[1] https://review.openstack.org/#/c/86947/7
[2] https://review.openstack.org/#/c/113058/, https://review.openstack.org/#/c/113059/, https://review.openstack.org/#/c/113060/
[3] The patch for enabling automatic transitioning is up on Gerrit.
    However, there are a couple of flaws in its implementation (not bugs, per se,
    but things I would like to fix none-the-less).  However, this patch is not needed
    for the previous patches to function properly, as they stand on their own.
[4] The only significant change not behind a configuration option is the change that
    makes the image cache use a file-based storage pool to manage its images.  Since the
    pool is file-based and automatically created in the same location as the current image
    cache, there is little risk associated.


Best Regards,
Solly Ross