On Mon, Aug 22, 2016 at 9:48 PM, Loo, Ruby <[email protected]> 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" <[email protected]> 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: [email protected]?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
