Open Stack

>So I'm not sure that Kevin and Thierry's answers address Sukhdev's point.

I stated that I am happy to develop new APIs in Neutron. "So I'm all for
developing new APIs *as a community*"...

The important distinction I am making is that we can make new APIs (and we
do with routed networks as you mentioned, VLAN aware VMs, etc), but I don't
want to see the project just become a framework to make it even easier than
it is to define an arbitrary networking API.

>But I think that the point that Sukhdev raised - about other networking
projects being suggested because of Neutron being perceived as not flexible
enough

I'm explicitly stating that if someone wants Neutron to become more
flexible to develop arbitrary APIs that diverge across deployments even
more, that's not something I'm going to support. However, making it
flexible for operators/users by adding new vendor-agnostic APIs is
something I will encourage.

The reason I am stressing that distinction is because we have vendors that
want something like Gluon that allows them to define new arbitrary APIs
without upstreaming anything or working with the community to standardize
anything. I understand that may be useful for some artisanal NFV workloads,
but that's not the direction I want to take Neutron.

Flexibility for operators/users = GOOD
Flexibility for vendor API injection = BAD

On Wed, Jan 25, 2017 at 4:55 AM, Neil Jerram <neil at tigera.io> wrote:

> On Wed, Jan 25, 2017 at 10:20 AM Thierry Carrez <thierry at openstack.org>
> wrote:
>
>> Kevin Benton wrote:
>> > [...]
>> > 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.
>>
>> +1000 on this being a major problem in Neutron. Happy to see that you
>> want to work on trying to reduce it.
>
>
> The Neutron API is a model of what forms of connectivity can be expressed,
> between instances and the outside world.  Once that model is chosen, it is
> inevitably (and simultaneously):
>
> (a) overconstraining - in other words, there will be forms of connectivity
> that someone could reasonably want, but that are not allowed by the model
>
> (b) underconstraining - in other words, there will be nuances of
> behaviour, delivered by a particular implementation, that are arguably
> within what the model allows, but (as we're talking about semantics) it
> would really be better to revise the API so that it can explicitly express
> those nuances.
>
> Sometimes - since the semantics of the Neutron API are not precisely
> documented - it's not clear which of these situations one is in.  But I
> think that the point that Sukhdev raised - about other networking projects
> being suggested because of Neutron being perceived as not flexible enough -
> is to do with (a); whereas the points that Kevin and Thierry responded with
> - ways that the API is already _too_ flexible - are to do with (b).  So I'm
> not sure that Kevin and Thierry's answers address Sukhdev's point.
>
> It's possible for an API to have (a) and (b) problems simultaneously, and
> to make progress on addressing them both.  In Neutron's case, a major
> example of (a) has been the routed networks work, which (among other
> things) generalized Neutron's network concept from being something that
> always provides L2 adjacency between its ports, to something that may or
> may not.  So it seems to me that Neutron is able to address (a) problems.
>  (I'm personally less familiar with (b), but would guess that progress is
> being made there too.)
>
> Regards,
>      Neil
>
>
> __________________________________________________________________________
> 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/cb79b72a/attachment.html>