Open Stack

Clay Gerrard <clay.gerrard at gmail.com> wrote:

> The  
> use_untested_probably_broken_deprecated_manger_so_maybe_i_can_migrate_cross_fingers  
> option sounds good!  The experiment would be then if it's still enough of  
> a stick to keep 3rd party drivers pony'd up on their commitment to the  
> Cinder team to consistently ship quality releases?
>

This commitment, is it the only model that you allow to extend Cinder for  
vendor technology? Because if not, then, in a way, you put vendors in an  
unfortunate situation where they are forced into a very specific model of  
commitment, that may be not in the best interest of that vendor. While  
there may be a value of keeping multiple drivers closer to the core code  
(code reusability, spotting common patterns, …), I feel that the benefit  
from such collaboration is worthwhile only when it's mutual, and not forced  
onto.

I assume that if there would be alternatives available (including walking  
autonomously of Cinder release cycles and practices), then some of those  
vendors that you currently try hard to police into doing things the right  
and only way would actually choose that alternative path, that could be  
more in line with their production cycle. And maybe those vendors that  
break current centralized rules would voluntarily vote for leaving the tree  
to pursuit happiness as they see it, essentially freeing you from the need  
to police code that you cannot actually maintain.

> What about maybe the operator just not upgrading till post migration?   
> It's the migration that sucks right?  You either get to punt a release  
> and hope it gets "back in good faith" or do it now and that 3rd party  
> driver has lost your business/trust.

The deprecation tag indicates a good will of the community to do whatever  
it takes to fulfill the guarantee that a solution that worked in a previous  
cycle won’t be dropped with no prior notice (read: deprecation warnings in  
logs). Explicitly removing a driver just because you *think* it may no  
longer work is not in line with this thinking. Yes, there may be bugs in  
the code, but there is at least a path forward: for one, operators may try  
to fix bugs they hit in upgrade, or they can work with the vendor to fix  
the code and backport the needed fixes to stable branches. When you don’t  
have the code in tree at all, it’s impossible to backport, because stable  
branches don’t allow new features. And it’s not possible to play with  
(potentially broken) driver to understand which bugs block you from going  
forward.

Ihar