On Tue, Sep 6, 2016 at 4:24 PM, Jim Rollenhagen <j...@jimrollenhagen.com> wrote: > On Mon, Aug 29, 2016 at 5:03 AM, Lucas Alvares Gomes > <lucasago...@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 <vd...@mirantis.com> wrote: >>> >>> On Mon, Aug 22, 2016 at 9:48 PM, Loo, Ruby <ruby....@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" <j...@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-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 >>>> >>> >>> >>> __________________________________________________________________________ >>> 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 __________________________________________________________________________ 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
