Open Stack

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.

Deprecating the CLI OVS Interfaces
------------------------------------------------
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.

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.

Refactoring the agent to use the callback framework
----------------------------------------------------------------------
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.

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.

However, any refactoring required for other development activities
(features or fixes), will not be blocked.

Eliminating L2pop as a mechanism driver
--------------------------------------------------------------------
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.

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.

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.

This change will likely need a small spec to scope out the new port binding
process.

Cheers,
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161109/8c9d4f9d/attachment.html>