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. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
