<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jan 25, 2017 at 10:20 AM Thierry Carrez <<a href="mailto:thierry@openstack.org">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="gmail_msg">
> [...]<br class="gmail_msg">
> The Neutron API is already very extensible and that's problematic. Right<br class="gmail_msg">
> now a vendor can write an out-of-tree service plugin or driver that adds<br class="gmail_msg">
> arbitrary fields and endpoints to the API that results in whatever<br class="gmail_msg">
> behavior they want. This is great for vendors because they can directly<br class="gmail_msg">
> expose features without having to make them vendor agnostic. However,<br class="gmail_msg">
> it's terrible for operators because it leads to lock-in and terrible for<br class="gmail_msg">
> the users because it leads to cross-cloud compatibility issues.<br class="gmail_msg">
<br class="gmail_msg">
+1000 on this being a major problem in Neutron. Happy to see that you<br class="gmail_msg">
want to work on trying to reduce it.</blockquote><div><br></div><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>