<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 19, 2016 at 5:15 PM, Jim Rollenhagen <span dir="ltr"><<a href="mailto:jim@jimrollenhagen.com" target="_blank">jim@jimrollenhagen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ironickers,<br>
<br>
There was a big thread here[0] about Cinder, driver removal, and standard<br>
deprecation policy. If you haven't read through it yet, please do before<br>
continuing here. :)<br>
<br>
The outcome of that thread is summarized well here.[1]<br>
<br>
I know that I previously had a different opinion on this, but I think we<br>
should go roughly the same route, for the sake of the users.<br>
<br>
1) A ``supported`` flag for each driver that is True if and only if the driver<br>
   is tested in infra or third-party CI (and meets our third party CI<br>
   requirements).<br>
2) If the supported flag is False for a driver, deprecation is implied (and<br>
   a warning is emitted at load time). A driver may be removed per standard<br>
   deprecation policies, with turning the supported flag False to start the<br>
   clock.<br>
3) Add a ``enable_unsupported_drivers`` config option that allows enabling<br>
   drivers marked supported=False. If a driver is in enabled_drivers, has<br>
   supported=False, and enable_unsupported_drivers=<wbr>False, ironic-conductor<br>
   will fail to start. Setting enable_unsupported_drivers=<wbr>True will allow<br>
   ironic-conductor to start with warnings emitted.<br></blockquote><div><br></div><div>Just for clarity, its default value is False?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It is important to note that (3) does still technically break the standard<br>
deprecation policy (old config may not work with new version of ironic).<br>
However, this is a much softer landing than the original plan. FWIW, I do<br>
expect (but not hope!) this part will be somewhat contentious.<br>
<br>
I'd like to hear thoughts and get consensus on this from the rest of the<br>
ironic community, so please do reply whether you agree or disagree.<br>
<br>
I'm happy to do the work required (update spec, code patches, doc updates)<br>
when we do come to agreement.<br>
<br>
// jim<br>
<br>
[0] <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-August/101428.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2016-<wbr>August/101428.html</a><br>
[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-August/101898.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2016-<wbr>August/101898.html</a><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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br></div></div>