<p dir="ltr">There's so much misinformation in that email I barely know where to start. </p>
<p dir="ltr">There is nothing stopping out of tree drivers for cinder, and a few have existed, though they don't seem to stick around. The driver is just a python class referenced in the config file.</p>
<p dir="ltr">Turning a removed driver into an out of tree driver (or patching it back into the tree) is trivial for anybody with basic python skills. They can even just apply a reverse patch of the removal patch directly and cleanly most of the time, since the drivers are clearly separated.</p>
<p dir="ltr">As has been said in the thread multiple times, by multiple people, the idea of out of tree drivers has been discussed, passionately and at vast length, with people on both sides of the debate. We've got storage vendors, operators and distribution packagers at every single one of these discussions, and have had each time it is discussed, which has been at least the last three summits and the last three mid cycles.</p>
<p dir="ltr">It is getting tiring and distracting to keep rehashing that decision in thread with nothing new being said, with somebody who neither has a driver nor otherwise contributes to cinder. Please have the curtsey to follow some of the provided historical references before repeatedly derailing the thread by expounding the virtues of out of tree drivers. They have been discussed, and soundly (though not unanimously, as Mike points out) rejected. We have clearly decided there is a consensus that they aren't what we want now. That is not what we're trying to discuss here.</p>
<p dir="ltr">To spell it pot one more time: we don't stop out of tree drivers. They work, they're easy. We don't advertise them as supported because they're not part of the review or testing process. We like in tree drivers. Vendors like in tree drivers, and the advertised support we give them for doing so. They will handle the Burton of keeping a third party CI going to maintain that status, though a little begrudgingly - it has repeatedly and continuously been necessary to have the option of the (apparently substantial, given the effect it can have) threat of removal from tree in order to persuade them to put enough resources into keeping their CI going.</p>
<div class="gmail_extra"><br><div class="gmail_quote">On 13 Aug 2016 16:40, "Ihar Hrachyshka" <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Clay Gerrard <<a href="mailto:clay.gerrard@gmail.com" target="_blank">clay.gerrard@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The use_untested_probably_broken_d<wbr>eprecated_manger_so_maybe_i_ca<wbr>n_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?<br>
<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br>
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.<br>
<br>
Ihar<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote></div></div>