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