[openstack-dev] [neutron] PTL candidacy

Kevin Benton kevin at benton.pub
Wed Jan 25 01:04:18 UTC 2017


>I would really like us to discuss this issue head-on and see what is
missing in Neutron APIs and what would take to make them extensible so that
vendors do not run around trying to figure out alternative solutions....

The Neutron API is already very extensible and that's problematic. Right
now a vendor can write an out-of-tree service plugin or driver that adds
arbitrary fields and endpoints to the API that results in whatever behavior
they want. This is great for vendors because they can directly expose
features without having to make them vendor agnostic. However, it's
terrible for operators because it leads to lock-in and terrible for the
users because it leads to cross-cloud compatibility issues.

For a concrete example of what I mean, take a look at this extension here:
[1]. This is directly exposing vendor-specific things onto Neutron network
API payloads. Nobody can build any tooling that depends on those fields
without being locked into a specific vendor.

So what I would like to encourage is bringing API extension work into
Neutron-lib where we can ensure that the relevant abstractions are in place
and it's not just a pass-through to a bunch of vendor-specific features. I
would rather relax our constraint around requiring a reference
implementation for new extensions in neutron-lib than continue to encourage
developers to do expose whatever they want with the the existing extension
framework.

So I'm all for developing new APIs *as a community* to enable NFV use cases
not supported by the current APIs. However, I don't want to encourage or
make it easier for vendors to just build arbitrary extensions on top of
Neutron that expose backend details.

In my view, Neutron should provide a unified API for networking across
OpenStack clouds, not a platform for writing deployment-specific networking
APIs.

1.
https://github.com/Juniper/contrail-neutron-plugin/blob/19ad4bcee4c1ff3bf2d2093e14727866412a694a/neutron_plugin_contrail/extensions/contrail.py#L9-L22

Cheers,
Kevin Benton

On Tue, Jan 24, 2017 at 3:42 PM, Sukhdev Kapur <sukhdevkapur at gmail.com>
wrote:

>
> Ihar and Kevin,
>
> As our potential future PTLs, I would like to draw your attention to one
> of the critical issue regarding Neutron as "the" networking service in
> OpenStack.
>
> I keep hearing off and on that Neutron is not flexible to address many
> networking use cases and hence a new (or additional) networking project is
> needed. For example, to address the use cases around NFV (rigid resource
> inter-dependencies).  Another one keeps popping up is that it is very
> hard/difficult to add/enhance Neutron API - hence, I picked this one goal
> called out in Ihar's candidacy.
>
> I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible so that
> vendors do not run around trying to figure out alternative solutions....
>
> cheers..
> -Sukhdev
>
>
>
>
>> * Explore alternative ways to evolve Neutron API.  Piling up
>> extensions and allowing third parties to completely change core
>> resource behaviour is not ideal, and now that api-ref and API
>> consolidation effort in neutron-lib are closer to completion, we may
>> have better answers to outstanding questions than during previous
>> attempts to crack the nut. I would like to restart the discussion some
>> time during Pike.
>>
>
>
>
>
>>
>> Thanks for attention,
>> Ihar
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> 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/20170124/79f5850c/attachment.html>


More information about the OpenStack-dev mailing list