Open Stack

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].

[1] https://review.openstack.org/#/c/282180
[2] https://review.openstack.org/#/c/317309

BR
Zhiyuan

On Thu, 10 Nov 2016 at 04:31 Kevin Benton <kevin at benton.pub> wrote:

> 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
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
BR
Zhiyuan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161110/067a0c49/attachment.html>