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