Open Stack

On 01/24/2017 08:04 PM, Kevin Benton wrote:
>>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.

A billion times yes.



> 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
> <mailto: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:unsubscribe
>         <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <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
>