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