<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 24, 2017 at 5:04 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span>><span style="font-size:12.8px">I would really like us to discuss this issue head-on and see what is missing in Neutron APIs and what would take to make them extensible so that vendors do not run around trying to figure out alternative solutions....</span><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">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. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">For a concrete example of what I mean, take a look at this extension here: [1]. This is directly exposing vendor-specific things onto Neutron network API payloads. Nobody can build any tooling that depends on those fields without being locked into a specific vendor.</span></div></div></blockquote><div><br></div><div>I do not believe this is a good example. I believe this is for monolithic plugin (and probably pre-ML2 plugin time frame). If memory serves me right, there were no specific guidelines at the time. I am sure there are many other such examples relating to monolithic plugins. </div><div>However, I do get your point. Hence, the need to have a good look at the API so that it can provide way for vendors and operators to expose the strengths/features of their back-ends in a vendor agnostic fashion. </div><div><br></div><div>-Sukhdev</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">So what I would like to encourage is bringing API extension work into Neutron-lib where we can ensure that the relevant abstractions are in place and it's not just a pass-through to a bunch of vendor-specific features. I would rather relax our constraint around requiring a reference implementation for new extensions in neutron-lib than continue to encourage developers to do expose whatever they want with the the existing extension framework.</span></div><div><span style="font-size:12.8px"><br></span></div><div>So I'm all for developing new APIs *as a community* to enable NFV use cases not supported by the current APIs. However, I don't want to encourage or make it easier for vendors to just build arbitrary extensions on top of Neutron that expose backend details.</div><div><br></div><div>In my view, Neutron should provide a unified API for networking across OpenStack clouds, not a platform for writing deployment-specific networking APIs.</div><div><br></div><div><span style="font-size:12.8px">1. <a href="https://github.com/Juniper/contrail-neutron-plugin/blob/19ad4bcee4c1ff3bf2d2093e14727866412a694a/neutron_plugin_contrail/extensions/contrail.py#L9-L22" target="_blank">https://github.com/Juniper/<wbr>contrail-neutron-plugin/blob/1<wbr>9ad4bcee4c1ff3bf2d2093e1472786<wbr>6412a694a/neutron_plugin_contr<wbr>ail/extensions/contrail.py#L9-<wbr>L22</a></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Cheers,</span></div><div><span style="font-size:12.8px">Kevin Benton</span></div></div><div class="m_3678033721926059450HOEnZb"><div class="m_3678033721926059450h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 24, 2017 at 3:42 PM, Sukhdev Kapur <span dir="ltr"><<a href="mailto:sukhdevkapur@gmail.com" target="_blank">sukhdevkapur@gmail.com</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_extra"><div class="gmail_quote"><div><br></div><div>Ihar and Kevin, </div><div><br></div><div>As our potential future PTLs, I would like to draw your attention to one of the critical issue regarding Neutron as "the" networking service in OpenStack. </div><div><br></div><div>I keep hearing off and on that Neutron is not flexible to address many networking use cases and hence a new (or additional) networking project is needed. For example, to address the use cases around NFV (rigid resource inter-dependencies).  Another one keeps popping up is that it is very hard/difficult to add/enhance Neutron API - hence, I picked this one goal called out in Ihar's candidacy. </div><div><br></div><div>I would really like us to discuss this issue head-on and see what is missing in Neutron APIs and what would take to make them extensible so that vendors do not run around trying to figure out alternative solutions....</div><div><br></div><div>cheers..</div><span class="m_3678033721926059450m_-4568652114049342955HOEnZb"><font color="#888888"><div>-Sukhdev</div></font></span><span><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Explore alternative ways to evolve Neutron API.  Piling up<br>
extensions and allowing third parties to completely change core<br>
resource behaviour is not ideal, and now that api-ref and API<br>
consolidation effort in neutron-lib are closer to completion, we may<br>
have better answers to outstanding questions than during previous<br>
attempts to crack the nut. I would like to restart the discussion some<br>
time during Pike.<br></blockquote><div><br></div><div><br></div><div> </div></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><span>
Thanks for attention,<br>
Ihar<br>
<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.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>
</span></blockquote></div><br></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.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></blockquote></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.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></blockquote></div><br></div></div>