Clay Gerrard <clay.gerr...@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 __________________________________________________________________________ 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
