[openstack-dev] [ironic] Driver removal policies - should we make it softer?

Vladyslav Drok vdrok at mirantis.com
Tue Aug 23 14:55:11 UTC 2016


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160823/f83c2b61/attachment.html>


More information about the OpenStack-dev mailing list