openstack/cinder
Code Issues Proposed changes

Update driver removal policy

Browse Source 
This change follows the discussion of this issue at the 29 January
2020 Cinder weekly meeting.

Change-Id: I59d56889b28663a2248a7ba6cfad4f8260dfb9c8
This commit is contained in:
Brian Rosmaita 2020-01-29 18:01:06 -05:00
parent 819b4a0fc0
commit 98f08db858
1 changed files with 39 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
doc/source/drivers-all-about.rst
View File

@ -103,8 +103,45 @@ option ``enable_unsupported_driver=True`` in the driver's configuration
section of ``cinder.conf`` or the Cinder service will fail to load.
If the issue is not corrected before the next release, the driver will be
removed from the Cinder code repository per the standard OpenStack
deprecation policy.
eligible for removal from the Cinder code repository per the standard
OpenStack deprecation policy.
Driver Removal
--------------
**(Added January 2020**)
As stated above, an unsupported driver is eligible for removal during the
development cycle following the release in which it was marked 'unsupported'.
(For example, a driver marked 'unsupported' in the Ussuri release is eligible
for removal during the development cycle leading up to the Victoria release.)
During the Ussuri development cycle, the Cinder team decided that drivers
eligible for removal, at the discretion of the team, may remain in the code
repository *as long as they continue to pass OpenStack CI testing*. When such a
driver blocks the CI check or gate, it will be removed immediately. (This does
not violate the OpenStack deprecation policy because such a driver's
deprecation period began when it was marked as 'unsupported'.)
.. note::
Why the "at the discretion of the team" qualification? Some vendors may
announce that they have no intention of continuing to support a driver.
In that case, the Cinder team reserves the right to remove the driver as
soon as the deprecation period has passed.
Thus, unsupported drivers *may* remain in the code repository for multiple
releases following their declaration as 'unsupported'. Operators should
therefore take into account the length of time a driver has been marked
'unsupported' when deciding to deploy an unsupported driver. This is because
as an unmaintained driver ages, updates and bugfixes to libraries and other
software it depends on may cause the driver to fail unit and functional tests,
making it subject to immediate removal.
The intent of this policy revision is twofold. First, it gives vendors a
longer grace period in which to make the necessary changes to have their
drivers reinstated as 'supported'. Second, keeping these drivers in-tree
longer should make life easier for operators who have deployed storage backends
with drivers that have been marked as 'unsupported'. Operators should keep the
above points in mind, however, when deploying such a driver.
Current Cinder Drivers
~~~~~~~~~~~~~~~~~~~~~~