<div dir="ltr">It's cool to store tunnel termination endpoint information in the port model. Will this information support updating so external devices or controllers can inject the tunnel termination endpoints via the API? This is very useful to support VxLAN type external network, which there are already some patches working on it[1,2].<div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/282180">https://review.openstack.org/#/c/282180</a></div><div>[2] <a href="https://review.openstack.org/#/c/317309">https://review.openstack.org/#/c/317309</a></div></div><div><br></div><div>BR<br>Zhiyuan</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 10 Nov 2016 at 04:31 Kevin Benton <kevin@benton.pub> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr" class="gmail_msg">There were three main topics discussed during the neutron-agent retrospective session: deprecating the CLI OVS interfaces, refactoring the agent to use the callback framework, and eliminating the L2pop driver.<br class="gmail_msg"></p>
<p dir="ltr" class="gmail_msg">Deprecating the CLI OVS Interfaces<br class="gmail_msg">
------------------------------------------------<br class="gmail_msg">
We now have native replacements for shelling out to ovs-vsctl and ovs-ofctl using a python ovsdb interface and the RYU openflow code, respectively. Currently, it's an operator configuration option to choose the native vs legacy interfaces. The native interfaces were the default for the last cycle, so we would like to deprecate the legacy interfaces and remove them in Pike.</p>
<p dir="ltr" class="gmail_msg">This appeared to have general consensus, contingent on fixing a few parity bugs with the CLI interface for handling flows. If using the CLI interfaces is critical to a use case, please reply to this email because we will proceed with the deprecation otherwise.<br class="gmail_msg"></p>
<p dir="ltr" class="gmail_msg">Refactoring the agent to use the callback framework<br class="gmail_msg">
----------------------------------------------------------------------<br class="gmail_msg">
We need to refactor some of the main OVS agent file to make it more maintainable. The file itself contains over 2000 lines of python and the methods are insanely long and complex, making unit testing difficult and questionable in its efficacy. This makes adding new features scary, which slows down development.</p>
<p dir="ltr" class="gmail_msg">While there was nobody against refactoring the agent, we decided to defer this work due to the short nature of this cycle and the potential conflicts it will have with the next bullet point.</p>
<p dir="ltr" class="gmail_msg">However, any refactoring required for other development activities (features or fixes), will not be blocked.<br class="gmail_msg"></p>
<p dir="ltr" class="gmail_msg">Eliminating L2pop as a mechanism driver<br class="gmail_msg">
--------------------------------------------------------------------<br class="gmail_msg">
L2pop calculates information on the fly to determine tunnel termination endpoints. This is racey (out of order tunnel notifications are not handled) and leads to lots of complexity involving lookups to agent tables, etc. This also makes it very difficult to integrate external devices because they have no way of informing the agents of their tunnel termination endpoint.</p>
<p dir="ltr" class="gmail_msg">We'd like to formalize the tunnel termination point by adding it to the port binding data model just like other encapsulation details (bound segment, segmentation id, etc). This will allow mech drivers to bind ports not based on agents and allow seamless integration with agent-based ports. The L2pop server-side logic would go away since agents would setup forwarding entries just based on the latest data on the port models delivered via push notifications.</p>
<p dir="ltr" class="gmail_msg">This will require some changes on the server side in the port binding process to have the mech drivers provide the tunnel termination point as part of the binding details. The agent side will also require a few changes to have its tunnel forming logic be derived from push notifications instead of tunnel and fdb notifications.</p>
<p dir="ltr" class="gmail_msg">This change will likely need a small spec to scope out the new port binding process.</p>
<p dir="ltr" class="gmail_msg">Cheers,<br class="gmail_msg">
Kevin Benton</p>
__________________________________________________________________________<br class="gmail_msg">
OpenStack Development Mailing List (not for usage questions)<br class="gmail_msg">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="gmail_msg" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="gmail_msg">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="gmail_msg">
</blockquote></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">BR<div>Zhiyuan</div></div></div>