Catching up on the thread, lots of good thoughts. I don't think there is disagreement here around how Networking API should evolve in terms of vendor extensions. As Kevin suggested, we don't want to advertise API extensibility without Neutron team supervision.
One of the reasons behind current api-ref effort that includes moving API definitions from all stadium projects into neutron-lib - and vouching for new API changes in scope of this single repo - is to transform Neutron from a shallow API controller that allows to plug in opaque API modules into a single API with consistent behavior, review practices and standards. I would go as far as to say that once that effort is complete, we should start looking for ways to discourage (if not forbid) API pluggability not proxied through proper in-neutron-lib review process. It's one thing to allow plugging in different networking backends that all implement the same Networking API behavior; and it's completely different to allow those plugins to change Networking API to the point where you can't even tell if it's open API guaranteed to work in other environments. Yes, there is concern that Networking API doesn't move as quick as some vendors may want. We can address that with streamlining review process for new API definitions. As long as an API proposal makes sense not just for one specific backend, and is defined in general enough terms, I think we can go with expedited review procedure. Indeed we should probably reconsider how we enforce reference implementation completion before an extension is allowed in. Ihar 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: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 > __________________________________________________________________________ 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