On Tue, Jan 24, 2017 at 5:04 PM, Kevin Benton <ke...@benton.pub> 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. > I do not believe this is a good example. I believe this is for monolithic plugin (and probably pre-ML2 plugin time frame). If memory serves me right, there were no specific guidelines at the time. I am sure there are many other such examples relating to monolithic plugins. However, I do get your point. Hence, the need to have a good look at the API so that it can provide way for vendors and operators to expose the strengths/features of their back-ends in a vendor agnostic fashion. -Sukhdev > 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/1 > 9ad4bcee4c1ff3bf2d2093e14727866412a694a/neutron_plugin_contr > ail/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.op >>> enstack.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: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
