Open Stack

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.

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
>