<div dir="ltr"><div class="gmail_extra">Folks, this is a great discussion. I hope this leads us to some good consensus and direction :-)</div><div class="gmail_extra">I would suggest that we discuss this in upcoming PTG meeting as well. <br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 25, 2017 at 5:20 AM, Kevin Benton <span dir="ltr"><<a href="mailto:kevin@benton.pub" target="_blank">kevin@benton.pub</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="gmail-">><span style="font-size:12.8px">So I'm not sure that Kevin and Thierry's answers address Sukhdev's point.</span><div><br></div></span><div>I stated that I am happy to develop new APIs in Neutron. "<span style="font-size:12.8px">So I'm all for developing new APIs *as a community*"...</span></div></div></blockquote><div><br></div><div>+1  </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div></div></blockquote><div><br></div><div>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. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span class="gmail-"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">></span><span style="font-size:12.8px">But I think that the point that Sukhdev raised - about other networking projects being suggested because of Neutron being perceived as not flexible enough</span><br></div><div><span style="font-size:12.8px"><br></span></div></span><div>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.</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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. </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I understand that may be useful for some artisanal NFV workloads, but that's not the direction I want to take Neutron.</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Flexibility for operators/users = GOOD</div><div>Flexibility for vendor API injection = BAD</div></div></blockquote><div><br></div><div>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 :-):-)</div><div><br></div><div>cheers..</div><div>-Sukhdev</div><div> </div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-h5">On Wed, Jan 25, 2017 at 4:55 AM, Neil Jerram <span dir="ltr"><<a href="mailto:neil@tigera.io" target="_blank">neil@tigera.io</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><div dir="ltr"><div class="gmail_quote"><span><div dir="ltr">On Wed, Jan 25, 2017 at 10:20 AM Thierry Carrez <<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Kevin Benton wrote:<br class="gmail-m_5451796629694173786m_2061899133641051866gmail_msg">
> [...]<br class="gmail-m_5451796629694173786m_2061899133641051866gmail_msg">
> The Neutron API is already very extensible and that's problematic. Right<br class="gmail-m_5451796629694173786m_2061899133641051866gmail_msg">
> now a vendor can write an out-of-tree service plugin or driver that adds<br class="gmail-m_5451796629694173786m_2061899133641051866gmail_msg">
> arbitrary fields and endpoints to the API that results in whatever<br class="gmail-m_5451796629694173786m_2061899133641051866gmail_msg">
> behavior they want. This is great for vendors because they can directly<br class="gmail-m_5451796629694173786m_2061899133641051866gmail_msg">
> expose features without having to make them vendor agnostic. However,<br class="gmail-m_5451796629694173786m_2061899133641051866gmail_msg">
> it's terrible for operators because it leads to lock-in and terrible for<br class="gmail-m_5451796629694173786m_2061899133641051866gmail_msg">
> the users because it leads to cross-cloud compatibility issues.<br class="gmail-m_5451796629694173786m_2061899133641051866gmail_msg">
<br class="gmail-m_5451796629694173786m_2061899133641051866gmail_msg">
+1000 on this being a major problem in Neutron. Happy to see that you<br class="gmail-m_5451796629694173786m_2061899133641051866gmail_msg">
want to work on trying to reduce it.</blockquote><div><br></div></span><div>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):</div><div><br></div><div>(a) overconstraining - in other words, there will be forms of connectivity that someone could reasonably want, but that are not allowed by the model</div><div><br></div><div>(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.</div><div><br></div><div>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.</div><div><br></div><div>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.)</div><div><br></div><div>Regards,</div><div>     Neil</div><div><br></div></div></div>
<br></div></div><span class="gmail-">______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br></span></blockquote></div><br></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div></div>