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/ __________________________________________________________________________ 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
