Open Stack

On 09/02/2016 12:40 PM, Eric Harney wrote:
> 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.

It's important to remember that there are 2 goals behind the current policy:

1) Protect end users from buggy/unmaintained drivers.

2) Motivate vendors to actively maintain their drivers by associating a 
painful consequence with not maintaining them.

Most of this discussion seems to be about alternative ways to address 
the first goal. However the second goal is in direct conflict with many 
of the proposed solutions. The more kind and gentle the approach is to 
deprecating drivers, the less effective it will be as a motivator for 
vendors.

Personally I'm of 2 minds about this. I think it's useful for the 
community to have a stick to beat vendors with to keep drivers 
maintained, and I think backing off the current driver deletion policy 
would turn that stick into a nerf bat. However I also think that in the 
long run the market will punish vendors who do a bad job of writing and 
maintaining drivers and the community probably doesn't need to expend as 
much effort as it does policing driver quality.

-Ben Swartzlander


> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>