[neutron] OVS OpenFlow L3 DVR / dvr_bridge agent_mode

Miguel Lavalle miguel at mlavalle.com
Sat Feb 2 01:06:42 UTC 2019


Hi Igor,

Please see my comments in-line below

On Tue, Jan 29, 2019 at 1:26 AM Duarte Cardoso, Igor <
igor.duarte.cardoso at intel.com> wrote:

> Hi Neutron,
>
>
>
> I've been internally collaborating on the ``dvr_bridge`` L3 agent mode
> [1][2][3] work (David Shaughnessy, Xubo Zhang), which allows the L3 agent
> to make use of Open vSwitch / OpenFlow to implement ``distributed`` IPv4
> Routers thus bypassing kernel namespaces and iptables and opening the door
> for higher performance by keeping packets in OVS for longer.
>
>
>
> I want to share a few questions in order to gather feedback from you. I
> understand parts of these questions may have been answered in the past
> before my involvement, but I believe it's still important to revisit and
> clarify them. This can impact how long it's going to take to complete the
> work and whether it can make it to stein-3.
>
>
>
> 1. Should OVS support also be added to the legacy router?
>
> And if so, would it make more sense to have a new variable (not
> ``agent_mode``) to specify what backend to use (OVS or kernel) instead of
> creating more combinations?
>

I would like to see the legacy router also implemented. And yes, we need to
specify a new config option. As it has already been pointed out, we need to
separate what the agent does in each host from the backend technology
implementing the routers.


>
>
> 2. What is expected in terms of CI for this? Regarding testing, what
> should this first patch include apart from the unit tests? (since the
> l3_agent.ini needs to be configured differently).
>

I agree with Slawek. We would like to see a scenario job.


>
>
> 3. What problems can be anticipated by having the same agent managing both
> kernel and OVS powered routers (depending on whether they were created as
> ``distributed``)?
>
> We are experimenting with different ways of decoupling RouterInfo (mainly
> as part of the L3 agent refactor patch) and haven't been able to find the
> right balance yet. On one end we have an agent that is still coupled with
> kernel-based RouterInfo, and on the other end we have an agent that either
> only accepts OVS-based RouterInfos or only kernel-based RouterInfos
> depending on the ``agent_mode``.
>

I also agree with Slawek here. It would a good idea if we can get the two
efforts in synch so we can untangle RouterInfo from the agent code


>
>
> We'd also appreciate reviews on the 2 patches [4][5]. The L3 refactor one
> should be able to pass Zuul after a recheck.
>
>
>
> [1] Spec:
> https://blueprints.launchpad.net/neutron/+spec/openflow-based-dvr
>
> [2] RFE: https://bugs.launchpad.net/neutron/+bug/1705536
>
> [3] Gerrit topic:
> https://review.openstack.org/#/q/topic:dvr_bridge+(status:open+OR+status:merged)
>
> [4] L3 agent refactor patch: https://review.openstack.org/#/c/528336/29
>
> [5] dvr_bridge patch: https://review.openstack.org/#/c/472289/17
>
>
>
> Thank you!
>
>
>
> Best regards,
>
> Igor D.C.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190201/e8db34d1/attachment.html>


More information about the openstack-discuss mailing list