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


The patches in question [2] would entail adding support for libvirt storage 
but neither making them default nor adding in automatic transitioning [3] from 
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.


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


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 
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/, 
[3] The patch for enabling automatic transitioning is up on Gerrit.
    However, there are a couple of flaws in its implementation (not bugs, per 
    but things I would like to fix none-the-less).  However, this patch is not 
    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 
    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

OpenStack-dev mailing list

Reply via email to