hi, On Mon, Nov 25, 2019 at 5:00 PM Slawek Kaplonski <skaplons@redhat.com> wrote:
Hi,
I think that this may be true that networking-ovn will not work properly with other drivers. I don't think it was tested at any time. Also the problem may be that when You are using networking-ovn than whole neutron topology is different. There are different agents for example.
Please open a bug for that for networking-ovn. I think that networking-ovn team will take a look into that.
networking-midonet ignores networks without "midonet" type segments to avoid interfering other mechanism drivers. maybe networking-ovn can have something similar. wrt agents, last time i checked there was no problem with running midonet agent and ovs agent on the same host, sharing the kernel datapath. so i guess there's no problem with ovn either. wrt l3, unfortunately neither midonet or ovn have implemented "l3 flavor" thing yet. so you have to choose a single l3 plugin. iirc, Sam's deployment doesn't use l3 for linuxbridge, right?
On Mon, Nov 25, 2019 at 04:32:50PM +1100, Sam Morrison wrote:
We are looking at using OVN and are having some issues with it in our ML2 environment.
We currently have 2 mechanism drivers in use: linuxbridge and midonet and these work well (midonet is the default tenant network driver for when users create a network)
Adding OVN as a third mechanism driver causes the linuxbridge and midonet networks to stop working in terms of CRUD operations etc. It looks as if the OVN driver thinks it’s the only player and is trying to do things on ports that are in linuxbridge or midonet networks.
Am I missing something here? (We’re using Stein version)
Thanks, Sam
-- Slawek Kaplonski Senior software engineer Red Hat