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 <sukhdevka...@gmail.com > <mailto:sukhdevka...@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-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@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-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