Open Stack

On 19/08/2016 18:44, "Villalovos, John L" <john.l.villalovos at intel.com>
wrote:

>> -----Original Message-----
>> From: Jim Rollenhagen [mailto:jim at jimrollenhagen.com]
>> Sent: Friday, August 19, 2016 7:15 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev at 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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev