[openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed

Eric Harney eharney at redhat.com
Fri Sep 2 16:40:17 UTC 2016


On 08/15/2016 04:48 AM, Thierry Carrez wrote:
> Sean Dague wrote:
>> On 08/12/2016 01:10 PM, Walter A. Boring IV wrote:
>>> I believe there is a compromise that we could implement in Cinder that
>>> enables us to have a deprecation
>>> of unsupported drivers that aren't meeting the Cinder driver
>>> requirements and allow upgrades to work
>>> without outright immediately removing a driver.
>>>
>>>  1. Add a 'supported = True' attribute to every driver.
>>>  2. When a driver no longer meets Cinder community requirements, put a
>>>     patch up against the driver
>>>  3. When c-vol service starts, check the supported flag.  If the flag is
>>>     False, then log an exception, and disable the driver.
>>>  4. Allow the admin to put an entry in cinder.conf for the driver in
>>>     question "enable_unsupported_driver = True".  This will allow the
>>>     c-vol service to start the driver and allow it to work.  Log a
>>>     warning on every driver call.
>>>  5. This is a positive acknowledgement by the operator that they are
>>>     enabling a potentially broken driver. Use at your own risk.
>>>  6. If the vendor doesn't get the CI working in the next release, then
>>>     remove the driver. 
>>>  7. If the vendor gets the CI working again, then set the supported flag
>>>     back to True and all is good. 
>>>
>>> This allows a deprecation period for a driver, and keeps operators who
>>> upgrade their deployment from losing access to their volumes they have
>>> on those back-ends.  It will give them time to contact the community
>>> and/or do some research, and find out what happened to the driver.  
>>> This also potentially gives the operator time to find a new supported
>>> backend and start migrating volumes.  I say potentially, because the
>>> driver may be broken, or it may work enough to migrate volumes off of it
>>> to a new backend.
>>>
>>> Having unsupported drivers in tree is terrible for the Cinder community,
>>> and in the long run terrible for operators.
>>> Instantly removing drivers because CI is unstable is terrible for
>>> operators in the short term, because as soon as they upgrade OpenStack,
>>> they lose all access to managing their existing volumes.   Just because
>>> we leave a driver in tree in this state, doesn't mean that the operator
>>> will be able to migrate if the drive is broken, but they'll have a
>>> chance depending on the state of the driver in question.  It could be
>>> horribly broken, but the breakage might be something fixable by someone
>>> that just knows Python.   If the driver is gone from tree entirely, then
>>> that's a lot more to overcome.
>>>
>>> I don't think there is a way to make everyone happy all the time, but I
>>> think this buys operators a small window of opportunity to still manage
>>> their existing volumes before the driver is removed.  It also still
>>> allows the Cinder community to deal with unsupported drivers in a way
>>> that will motivate vendors to keep their stuff working.
>>
>> This seems very reasonable. It allows the cinder team to mark stuff
>> unsupported at any point that vendors do not meet their upstream
>> commitments, but still provides some path forward for operators that
>> didn't realize their chosen vendor abandoned them and the community
>> until after they are in the midst of upgrade. It's very important that
>> the cinder team is able to keep a very visible hammer for vendors not
>> living up to their commitments.
>>
>> Keeping some visible data around drivers that are flapping (going
>> unsupported, showing up with CI to get back out of the state,
>> disappearing again) would be great as well, to further give operators
>> data on what vendors are working in good faith and which aren't.
> 
> I like this a lot, and it certainly would address the deprecation policy
> part.
> 
> Sean: I was wondering if that would not still be considered breaking
> upgrades, though... Since you end up upgrading and your c-vol would not
> restart until you set enable_unsupported_driver = True ?
> 

Kind of late jumping in here, but I'm curious what you guys think on
this last point.

I have a similar feeling, that this may still be breaking upgrades in an
undesirable way.

There are softer alternatives that could still communicate that a driver
is unsupported and not halt the upgrade path, such as printing warning
messages when the c-vol service starts up, etc.




More information about the OpenStack-dev mailing list