Open Stack

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 ?

-- 
Thierry Carrez (ttx)