Open Stack

Folks, this is a great discussion. I hope this leads us to some good
consensus and direction :-)
I would suggest that we discuss this in upcoming PTG meeting as well.


On Wed, Jan 25, 2017 at 5:20 AM, Kevin Benton <kevin at benton.pub> wrote:

> >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*"...
>

+1


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

There is no such thing as arbitrary API. It is like one person's treasure
is other person's trash.... no body loves to create arbitrary APIs - there
are genuine needs. Some times we fail to understand requirements, other
times the requirements are not articulated clearly, which could lead to
impressions that arbitrary things are being added.



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

OpenStack community consists of vendors and operators/users to facilitate
and adoption of newer technologies as they evolve. As newer
workloads/technologies evolve, the need to orchestrate them requires
flexibility in the API. Labeling them as an arbitrary API  just because
they do not fall into traditional L2/L3 networking model) is a harsh
characterization.



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

As I read/understand more about Gluon, that is being pushed by both
Operators/Users and Vendors. I wonder which one is GOOD and which one is
BAD :-):-)

cheers..
-Sukhdev




>
> 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:unsubscrib
>> e
>> 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/67c6b131/attachment.html>