Open Stack

In my opinion, we have to be careful about the "supported" label. Saying
that third-party tested drivers are community supported implies a
commitment that may have not been intended.

Personally, I see no problem with leaving everything just as planned.
Drivers that are in tree are either tested upstream in infra, or they are
tested against the third-party requirements that we defined. We have
communicated the plan to move drivers out of tree for more than a release.
And, I am absolutely against shipping a driver that has not been tested,
regardless of if it was previously in tree or not, regardless of the
deprecation policy.

Nova takes an even harder position on this by simply stating that if a
driver is not tested in upstream infra, it is unsupported, regardless of
where the driver lives or how good (or not) the third-party system testing
it has done their job.

kurt (krtaylor)

On Mon, Aug 22, 2016 at 1: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?
>
>
>
> 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" <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/20160822/14a276e0/attachment.html>