<div dir="ltr">><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><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><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><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><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><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. I understand that may be useful for some artisanal NFV workloads, but that's not the direction I want to take Neutron.</div><div><br></div><div>Flexibility for operators/users = GOOD</div><div>Flexibility for vendor API injection = BAD</div></div><div class="gmail_extra"><br><div class="gmail_quote">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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Kevin Benton wrote:<br class="m_2061899133641051866gmail_msg">
> [...]<br class="m_2061899133641051866gmail_msg">
> The Neutron API is already very extensible and that's problematic. Right<br class="m_2061899133641051866gmail_msg">
> now a vendor can write an out-of-tree service plugin or driver that adds<br class="m_2061899133641051866gmail_msg">
> arbitrary fields and endpoints to the API that results in whatever<br class="m_2061899133641051866gmail_msg">
> behavior they want. This is great for vendors because they can directly<br class="m_2061899133641051866gmail_msg">
> expose features without having to make them vendor agnostic. However,<br class="m_2061899133641051866gmail_msg">
> it's terrible for operators because it leads to lock-in and terrible for<br class="m_2061899133641051866gmail_msg">
> the users because it leads to cross-cloud compatibility issues.<br class="m_2061899133641051866gmail_msg">
<br class="m_2061899133641051866gmail_msg">
+1000 on this being a major problem in Neutron. Happy to see that you<br class="m_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>______________________________<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>