[openstack-dev] [ironic] Driver removal policies - should we make it softer?

Jim Rollenhagen jim at jimrollenhagen.com
Tue Sep 6 22:27:53 UTC 2016


On Tue, Sep 6, 2016 at 4:24 PM, Jim Rollenhagen <jim at jimrollenhagen.com> wrote:
> On Mon, Aug 29, 2016 at 5:03 AM, Lucas Alvares Gomes
> <lucasagomes at gmail.com> wrote:
>> Hi,
>>
>> I overall agree with the proposed plan. I like the idea of having a
>> "supported" flag (or another name as per Kurt's email) that makes it
>> easy mark a driver as "unsupported" indicating it might be removed
>> soon.
>>
>> About point #3 I'm indifferent, it's a common approach in the project
>> to log a warning + release notes to mark something as deprecated and I
>> don't see the real benefit of having an extra Boolean flag to be able
>> to enable certain drivers, it just sounds like an extra pain. If a
>> driver is deprecated in the previous cycle and that
>> "enable_unsupported_drivers" is set to False (the default) after the
>> upgrading the Ironic services the conductor will fail to start and
>> operators will most likely just set it to True straight away. It's not
>> that trivial to replace the deprecated driver on all nodes that are
>> using it (specially if they are active) and IMO, only having the
>> warning message (and release notes) is enough and give people enough
>> time to replace the drivers when possible.
>
> Apologies for taking so long to respond to this thread again.
>
> Sounds like we have rough consensus, with some people expressing
> dislike for #3. Thinking about it more, I actually quite agree, we don't
> need that.
>
> I'll put up patches to make these changes today/tomorrow and we can follow
> up the discussion in Gerrit. Thanks all for chiming in. :)

FYI, the first patch is here: https://review.openstack.org/#/c/366399/

I'll be adding subsequent patches to mark drivers as unsupported, let's
first agree on the framework.

// jim

>
> // jim
>
>>
>> Cheers,
>> Lucas
>>
>> On Tue, Aug 23, 2016 at 3:55 PM, Vladyslav Drok <vdrok at mirantis.com> wrote:
>>>
>>> On Mon, Aug 22, 2016 at 9:48 PM, Loo, Ruby <ruby.loo at intel.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I admit, I didn't read the entire thread [0], but did read the summary
>>>> [1]. I like this, except that I'm not sure about #3. What's the rationale of
>>>> adding a new config option 'enable_unsupported_drivers' that defaults to
>>>> False. Versus not having it, and "just" logging a warning if they are
>>>> loading an unsupported (in-tree) driver?
>>>>
>>>>
>>>>
>>>> If I understand this...
>>>>
>>>>
>>>>
>>>> If we have 'enable_unsupported_drivers': since it defaults to False, the
>>>> conductor will fail on startup, if an unsupported driver is in the
>>>> enabled_drivers config. (The conductor will emit a warning in the logs, or
>>>> maybe it won't?) The operator (if they haven't changed it), will now change
>>>> it to True if they want to use any unsupported drivers. The conductor will
>>>> start up and emit a warning in the logs.
>>>>
>>>>
>>>>
>>>> If we don't have an enable_unsupported_drivers config, will the conductor
>>>> start up and emit a warning in the logs?
>>>
>>>
>>> We have not added any deprecation warnings to drivers. I think that just
>>> gives a bit more time to switch to other drivers and it will make the
>>> removal more visible, as the current spec states: "Third party driver teams
>>> that do not implement a reliable reporting CI test system by the N release
>>> feature freeze (see Deliverable milestones above) will be removed from the
>>> ironic source tree.", IIUC meaning that conductor will fail startup not
>>> being able to find the removed code.
>>>
>>>>
>>>>
>>>>
>>>> I was also wondering, where is the value for the 'supported' flag for each
>>>> driver going to be kept? Hard-coded in the driver code?
>>>
>>>
>>> Yep, seems like it.
>>>
>>>>
>>>>
>>>>
>>>> --ruby
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 2016-08-19, 10:15 AM, "Jim Rollenhagen" <jim at jimrollenhagen.com> wrote:
>>>>
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>
>> __________________________________________________________________________
>> 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



More information about the OpenStack-dev mailing list