>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 <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:unsubscrib >> e >> 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
