14:00:43 <slaweq> #startmeeting neutron_drivers
14:00:44 <openstack> Meeting started Fri Mar 13 14:00:43 2020 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:47 <slaweq> hi
14:00:48 <openstack> The meeting name has been set to 'neutron_drivers'
14:00:48 <jlibosva> o/
14:00:51 <mlavalle> o/
14:00:54 <njohnston> o/
14:00:57 <yamamoto> hi
14:01:10 <ralonsoh> hi
14:01:46 <maciejjozefczyk> hey!
14:01:53 <slaweq> I think that haleyb|away will not be here today but we can wait few more minutes for amotoki
14:05:15 <slaweq> ok, lets start
14:05:20 <slaweq> #topic RFEs
14:05:26 <slaweq> we have only 1 RFE to discuss today
14:05:36 <slaweq> https://bugs.launchpad.net/neutron/+bug/1865889
14:05:38 <openstack> Launchpad bug 1865889 in neutron "[RFE] Routed provider networks support in OVN" [Undecided,New]
14:06:13 <slaweq> I read it today but I'm definitely not an expert in either OVN driver and routed networks
14:06:29 <slaweq> so I hope that here we can have some discussion about it
14:07:14 <jlibosva> so I think regarding the rfe, we need to decide about the limitation described there - ie. if it's a stopper if one hypervisor can host VMs from only one segment. The second approach there won't be able to have two VMs from two different network segments on the same hypervisor
14:07:45 <njohnston> It makes intuitive sense to me that you would want a logical switch per segment.
14:08:32 <jlibosva> njohnston: that would be the correct way, yes. It's very invasive to ovn mech driver and will not have the limitation described above
14:08:38 <njohnston> jlibosva: what are the downsides of the first approach?
14:09:47 <jlibosva> njohnston: basically currently OVN maps networks to logical switches, we'd need to redesign the driver to map segments to logical switches instead - it's a huge change. That's the only downside and I don't think we'll be able to achieve that this late in the cycle
14:10:06 <maciejjozefczyk> njohnston, This solution will produce a lot of changes in OVN mech driver. We will need to modify a lot things there along with changing the code of maintanance tasks, sync tools and others.
14:11:31 <njohnston> ok, that makes sense. I just wanted to check and make sure that there isn’t something else also that would be a problem
14:11:55 <slaweq> but second approach requires changes in core ovn IIUC so this also would not be (probably) quick to do, right?
14:12:05 <jlibosva> it's actually technically a better solution :) just hard to make and will not need core OVN changes
14:12:06 <mlavalle> no
14:12:46 <maciejjozefczyk> slaweq, from what I remember there is agreement between the owner of this RFE and core-ovn developers, that the 2) approach is doable in core-ovn.
14:13:07 <maciejjozefczyk> based also on documentation:
14:13:08 <maciejjozefczyk> #link https://docs.openstack.org/neutron/train/admin/config-routed-networks.html
14:13:14 <mlavalle> the owner being Daniel?
14:13:19 <maciejjozefczyk> Usually we have one segment per compute
14:13:31 <maciejjozefczyk> mlavalle, Yes, Daniel Alvarez (dalvarez)
14:13:37 <njohnston> based on what I know about routes provider networks I don’t think having a host be on multiple segments is a valid choice, so option 2 is feasible.
14:13:43 <jlibosva> the second approach is already being discussed on ovs-discuss - https://mail.openvswitch.org/pipermail/ovs-discuss/2020-March/049793.html
14:14:09 <mlavalle> yeah, we don't support two segments per host
14:14:18 <mlavalle> it's been discussed, but not implemented
14:14:37 <jlibosva> we need to state that on the LP RFE, it's a crucial piece of information
14:15:01 <maciejjozefczyk> jlibosva, yes
14:16:06 <slaweq> so if we now don't support multiple segments per host, than approach 2) don't have any "real" downsides, correct?
14:16:31 <njohnston> right
14:16:33 <jlibosva> correct
14:17:32 <maciejjozefczyk> slaweq, for now no
14:18:02 <slaweq> so IMHO approach 2) sounds as good choice for now
14:18:14 <njohnston> I think that I would rather go for option 2 and let the neutron-ovn team be able to focus more on parity gaps between OVS and OVN.
14:18:34 <jlibosva> approach 2 also sounds like faster way to finish the rfe, assuming we have core OVN dev working on it
14:18:36 <mlavalle> yes, if we ever say that routed networks should support more than one segment per host, we are back to square number 1
14:20:38 <njohnston> I would say from the official drivers view that I endorse both options; if I was the OVN folks I would do #2 but if for someone reason that becomes impractical I am also fine with #1
14:21:37 * jlibosva nods
14:22:30 <mlavalle> yes, I have the same position
14:22:53 <mlavalle> I don't oppose either of the two options. Just giving perspective
14:23:31 <slaweq> yamamoto: any thoughts?
14:24:01 <yamamoto> i'm fine with letting ovn folks decide. honestly i'm not even sure why this needs to be a rfe.
14:24:06 <mlavalle> and I can say that at me employer we do use routed networks and haven't found the situation where we need more than one segment per host
14:24:23 <mlavalle> seems to be plenty
14:24:52 <slaweq> so it seems that this can be approved as rfe, and in fact ovn subteam can decide about which approach is better for them
14:25:05 <slaweq> is that correct summary?
14:25:09 <njohnston> +1
14:25:13 <mlavalle> yes and I would be interested in helping
14:25:28 <mlavalle> as a way to learn ovn
14:25:32 <jlibosva> mlavalle++ thanks for your inputs about one semgment per host :)
14:25:38 <jlibosva> s/semgment/segment/
14:25:45 <ralonsoh> +1 (but with some feedback from OVN core about feasibility)
14:25:57 <yamamoto> slaweq: +1
14:26:14 <slaweq> thx all, so I will mark this rfe as approved
14:26:26 <slaweq> and that's all what I have for today
14:26:32 <slaweq> #topic On Demand Agenda
14:26:41 <slaweq> do You have anything else You want to discuss today?
14:26:49 <mlavalle> not me
14:27:12 <yamamoto> do we want to have a rfe for each api to be implemented for ovn?
14:27:24 <yamamoto> like today's one
14:27:31 <ralonsoh> this is a huge change
14:27:36 <ralonsoh> this is not trivial at all
14:27:43 <ralonsoh> and needs to be handled in a RFE
14:27:43 <yamamoto> only huge ones?
14:27:47 <jlibosva> yamamoto: imho it was good to have it as rfe so we could discuss it here
14:28:19 <jlibosva> just my opinion :) not sure how much rfe differs from a regular bug except the approval process
14:28:39 <slaweq> I don't think that we will need to discuss any ovn related change here, lets decide "per LP" about that in the future :)
14:29:05 <yamamoto> ok
14:30:04 <yamamoto> i don't have anything else
14:30:43 <njohnston> nothing for me
14:31:05 <slaweq> ok, so lets have 30 minutes back today
14:31:08 <slaweq> thx for attending
14:31:13 <slaweq> and have a great weekend :)
14:31:15 <slaweq> o/
14:31:19 <slaweq> #endmeeting