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? 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? --ruby On 2016-08-19, 10:15 AM, "Jim Rollenhagen" <j...@jimrollenhagen.com<mailto: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<mailto: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
