Open Stack

Duncan Thomas wrote:
> Given the options, I'd agree with Sean and John that removing the tag is
> a far lesser evil than changing our policy.

Agree that the tag should be removed. The Cinder core certainly follows
standard deprecation policy, but the Cinder drivers are not.

> If we leave broken drivers in the tree, the end user (operator) is no
> better off - the thing they evaluated won't work - but it will be harder
> to tell why. The storage vendor won't suffer the pressure that comes
> from driver removal, so will have less incentive to fix their driver
> (there's enough examples of the threat of driver removal causing the
> immediate fix of things that have remained broken for months that we
> know, for certain that the policy works).

I agree that leaving broken drivers in tree is not significantly better
from an operational perspective. But I think the best operational
experience would be to have an idea of how much risk you expose yourself
when you pick a driver, and have a number of them that are actually
/covered/ by the standard deprecation policy.

So ideally there would be a number of in-tree drivers (on which the
Cinder team would apply the standard deprecation policy), and a separate
repository for 3rd-party drivers that can be removed at any time (and
which would /not/ have the follows-standard-deprecation-policy tag).

I understand that this kind of reorganization is a bit painful for
little (developer-side) gain, but I think it would provide the most
useful information to our users and therefore the best operational
experience...

-- 
Thierry Carrez (ttx)