Open Stack

"I'm partial to an "agent_mode" flag which will toggle the router..."

In my previous email I mention being in favor of not overloading
agent_mode, I realized I had a typo that might be confusing. I'm partial
to introducing something like "agent_backend" for toggling OVS vs.
namespace routers, not "agent_mode". Sorry for the typo.

-Ryan

On 1/31/19 10:02 AM, Ryan Tidwell wrote:
>
>
> On 1/29/19 1:25 AM, Duarte Cardoso, Igor 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?
>>
> Personally, I would like to see all routers implemented completely in
> the OVS data path. We can't do everything at once, so the DVR-first
> approach here seems reasonable to me. As to the question of config
> flags, agent_mode has a specific meaning. It effectively tells the
> agent what role it's playing (SNAT, SNAT_HA, etc.), not how to do it.
> dvr_bridge isn't a new mode, it's really a change to the backend
> implementation of the router (ie the "how"). Because of that, I'm
> partial to an "agent_mode" flag which will toggle the router
> implementation between OVS and namespace implementations.
>>
>>  
>>
>> 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).
>>
>>  
>>
>> 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``.
>>
>>  
>>
>> 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.
>>
>>  
>>
> -Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190131/b9ec634c/attachment.html>