<p dir="ltr"></p>
<p dir="ltr">On 12 Aug 2016 15:28, "Thierry Carrez" <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br>
><br>
> Duncan Thomas wrote:<br></p>
<p dir="ltr">> I agree that leaving broken drivers in tree is not significantly better<br>
> from an operational perspective. But I think the best operational<br>
> experience would be to have an idea of how much risk you expose yourself<br>
> when you pick a driver, and have a number of them that are actually<br>
> /covered/ by the standard deprecation policy.<br>
><br>
> So ideally there would be a number of in-tree drivers (on which the<br>
> Cinder team would apply the standard deprecation policy), and a separate<br>
> repository for 3rd-party drivers that can be removed at any time (and<br>
> which would /not/ have the follows-standard-deprecation-policy tag).</p>
<p dir="ltr">So we'd certainly have to move out all of the backends requiring proprietary hardware, since we couldn't commit to keeping them working if their vendors turn of their CI. That leaves ceph, lvm, NFS, drdb, and sheepdog, I think. There is not enough broad knowledge in the core team currently to support sheepdog or drdb without 'vendor' help. That would leave us with three drivers in the tree, and not actually provide much useful risk information to deployers at all.<br></p>
<p dir="ltr">> I understand that this kind of reorganization is a bit painful for<br>
> little (developer-side) gain, but I think it would provide the most<br>
> useful information to our users and therefore the best operational<br>
> experience...</p>
<p dir="ltr">In theory this might be true, but see above - in practice it doesn't work that way.</p>