Open Stack

On Thu, Aug 18, 2016 at 03:44:10AM +0000, Husheng (TommyLike, R&D IT&Tools Equipment Dept) wrote:
> Hi all,
> Sorry for absence from IRC meeting of this week and put forward this topic on driver deprecation policy again. Actually I support the driver support tag policy completely, it's a reasonable policy for both sides, and these below are my 2 concerns:
> 
> 1. With the release of driver deprecation policy, we may leave a negative impression on our customers/operators, cause we just send them a warning message while we bring out the unstable or unusable driver codes together . If I were the customer, I will probably not change my vendor for a few warning messages, so this is what may happen for the unlucky boys, they insist on their choice by setting the enable_unsupported_driver = TRUE and get stuck. So this action may let them to take the risk(result) of their own, maybe we can set up a guide of this situation rather than the announce possible result.

I'm not actually clear what you mean here for setting up "a guide of
this situation". Can you clarify that?

> 
> 2. As this is a big change for vendor teams to get noticed and keep. What's the detail rule of this policy, who or what will decide the vendor's support attribute. What's the deadline for vendor before we create the decisive patch. And when the vendor meets the standards again, what is the procedure followed for the customer to make their system work again. Do we need a document on all of this in detail?

Actually, this isn't a big change for vendor teams at all. This is
actually a smaller change for them versus the current policy of removing
the driver completely.
> 
> Thanks
> TommyLike.Hu
> 

For those that are just seeing this without the background context of
the other ML thread and the IRC discussions in Cinder, here's a little
summary.

It was raised in this thread [1] that Cinder's policy of removing
drivers that lacked vendor involvement and CI was against our current
tag of follows-standard-deprecation.

While a few options were discussed (I won't rehash them, but reading
through that thread should cover most of it), the current idea under
consideration is here: [2]

Rather than removing drivers, we would now mark them as deprecated and
add a flag to the driver that would indicate it is unsupported. On
initialization we would then be able to check for that flag and log very
clearly that it isn't considered a supported driver.

The one additional piece under consideration is whether or not to also
add a config file setting required to allow that driver to actually be
used. So an operator would need to set enable_unsupported_driver=True to
very explicitly acknowledge that they still want to be able to use the
driver.

Marking the driver as deprecated would then allow for some leeway (for
customers to angrily yell at their storage vendor to get their act
together) so that hopefully they would fix their CI issues and make sure
they are maintaining their driver. If they are able to turn things
around we can then remove that deprecation tag and unsupported flag and
everything's back to normal.

If however they don't turn things around and continue to ignore/abandon
their driver, we could then remove the driver for the next release and
not need to continue to keep around something that we have no idea if
still works. It allows us to follow the follows-standard-deprecation tag
intent better and gives users a release to make any necessary changes.

Feel free to comment on the review if you have any thoughts/concerns on
this.

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-August/101428.html
[2] https://review.openstack.org/#/c/355608/