[openstack-dev] [tc][cinder] tag:follows-standard-deprecation should be removed
thierry at openstack.org
Mon Aug 15 08:48:22 UTC 2016
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
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)
More information about the OpenStack-dev