> -----Original Message----- > From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com] > Sent: Friday, August 19, 2016 7:15 AM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [ironic] Driver removal policies - should we make it > softer? > > Hi Ironickers, > > There was a big thread here[0] about Cinder, driver removal, and standard > deprecation policy. If you haven't read through it yet, please do before > continuing here. :) > > The outcome of that thread is summarized well here.[1] > > I know that I previously had a different opinion on this, but I think we > should go roughly the same route, for the sake of the users. > > 1) A ``supported`` flag for each driver that is True if and only if the driver > is tested in infra or third-party CI (and meets our third party CI > requirements). > 2) If the supported flag is False for a driver, deprecation is implied (and > a warning is emitted at load time). A driver may be removed per standard > deprecation policies, with turning the supported flag False to start the > clock. > 3) Add a ``enable_unsupported_drivers`` config option that allows enabling > drivers marked supported=False. If a driver is in enabled_drivers, has > supported=False, and enable_unsupported_drivers=False, ironic- > conductor > will fail to start. Setting enable_unsupported_drivers=True will allow > ironic-conductor to start with warnings emitted. > > It is important to note that (3) does still technically break the standard > deprecation policy (old config may not work with new version of ironic). > However, this is a much softer landing than the original plan. FWIW, I do > expect (but not hope!) this part will be somewhat contentious. > > I'd like to hear thoughts and get consensus on this from the rest of the > ironic community, so please do reply whether you agree or disagree. > > I'm happy to do the work required (update spec, code patches, doc updates) > when we do come to agreement. > > // jim > > [0] http://lists.openstack.org/pipermail/openstack-dev/2016- > August/101428.html > [1] http://lists.openstack.org/pipermail/openstack-dev/2016- > August/101898.html
Thanks Jim. This proposal makes sense to me. So put me into the agree camp. __________________________________________________________________________ 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
