Open Stack

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. :)

// 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