On 19/08/2016 18:44, "Villalovos, John L" <john.l.villalo...@intel.com> wrote:
>> -----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. +1 from me too > >__________________________________________________________________________ >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 __________________________________________________________________________ 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
