Update driver removal policy
This change follows the discussion of this issue at the 29 January 2020 Cinder weekly meeting. Change-Id: I59d56889b28663a2248a7ba6cfad4f8260dfb9c8
This commit is contained in:
parent
819b4a0fc0
commit
98f08db858
@ -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.
|
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
|
If the issue is not corrected before the next release, the driver will be
|
||||||
removed from the Cinder code repository per the standard OpenStack
|
eligible for removal from the Cinder code repository per the standard
|
||||||
deprecation policy.
|
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
|
Current Cinder Drivers
|
||||||
~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
Loading…
x
Reference in New Issue
Block a user