Open Stack

LBaaS is a little special since Octavia will have it's own API endpoint
completely that they will evolve on their own. The other spun-out projects
(e.g. VPNaaS) will have the API defined in neutron-lib[1].

The specific DVR issue you are referring to with roaming IPs being the
target of floating IPs (I think that's what you're referring to) is
something I'm planning to address in Pike with the help of other DVR
contributors because floating IP translations for unbound addresses blocks
various other use cases.

1.
https://github.com/openstack/neutron-lib/blob/master/api-ref/source/v2/vpnaas.inc

On Wed, Jan 25, 2017 at 6:40 AM, Hayes, Graham <graham.hayes at hpe.com> wrote:

> 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>
> >
> >
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170125/3662a456/attachment.html>