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 <ke...@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 <n...@tigera.io> wrote: > >> On Wed, Jan 25, 2017 at 10:20 AM Thierry Carrez <thie...@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-requ...@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-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