Open Stack

On 25/01/2017 01:08, 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.

How does this tie in with the removal of some of the networking *aaS
projects from the stadium? I know LBaaS is doing a shim API layer in
the short term, but long term that will have to move to a separate API.

How do you think this will impact inter service bugs (e.g. Octavia HA +
Neutron DVR issues that have been around for cycles)

>
> 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>
>
>