14:07:09 <lajoskatona1> #startmeeting neutron_drivers 14:07:09 <opendevmeet> Meeting started Fri Oct 1 14:07:09 2021 UTC and is due to finish in 60 minutes. The chair is lajoskatona1. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:07:09 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:07:09 <opendevmeet> The meeting name has been set to 'neutron_drivers' 14:07:24 <lajoskatona1> Sorry, I disappeared without notice from the channel... 14:07:25 <mlavalle> seems lajoskatona is having problems with his connection 14:07:35 <ralonsoh> hi 14:07:35 <mlavalle> o/ 14:07:38 <slaweq> o/ 14:07:42 <lajoskatona1> Hi 14:07:44 <amotoki> o/ 14:08:14 <njohnston> o/ 14:08:46 <lajoskatona1> So we have only on etopic for today which is stateless firewall for OVS: https://bugs.launchpad.net/neutron/+bug/1885261 14:09:29 <lajoskatona1> It was asked by Liu to see if the community likes the idea to add it: https://meetings.opendev.org/meetings/networking/2021/networking.2021-09-28-14.00.log.html#l-124 14:09:55 <obondarev> hi 14:10:15 <lajoskatona1> On Tuesday the discussion was at the point to have it in neutron as a separate fw driver (see the meeting log above) 14:11:33 <slaweq> I don't think it would be good to keep it as new driver 14:11:45 <slaweq> in case of iptables_hybrid it's the same driver still 14:12:02 <slaweq> and can do both stateless and stateful SGs 14:12:03 <lajoskatona1> Some administratie question: do we need a spec for it? personally I think it's not necessary 14:12:05 <slaweq> IIRC 14:12:39 <lajoskatona1> yes for that we have a new API field, that can be used now as well 14:13:00 <obondarev> +1 for no need new driver 14:13:08 <amotoki> agree with slaweq. IIRC stateless and stateful SG cannot be used in a same SG but both of them can be used in a same deployment. 14:13:08 <slaweq> regarding spec IMVHO we should have something what will describe how flows will be done in that case 14:13:24 <njohnston> +1 agree with slaweq 14:13:38 <slaweq> it don't need to be spec, but maybe good documentation together with code should be required 14:13:54 <lajoskatona1> ok 14:14:15 <mlavalle> docs are always good 14:14:27 <slaweq> and now I would like to ask ralonsoh about how hard it can be to make it working :) 14:14:31 <ralonsoh> both FW drivers are differents, this is not mixing stateless and stateful rules 14:14:36 <slaweq> as he worked on something like that in the past probably 14:14:42 <ralonsoh> this is like openswitch and hybrid 14:14:50 <ralonsoh> so the point here is to have another driver 14:15:03 <ralonsoh> but you can always create a plugin and create an entry point 14:15:10 <ralonsoh> as in networking-ovs-dpdk 14:15:25 <ralonsoh> (this is the FW liu's wants to re-implement) 14:16:15 <lajoskatona1> ok, so your point is that we cant mix and select on the fly? 14:16:21 <slaweq> ralonsoh: are You saying that in case of ovs fw, we can't have mixed stateless and stateful SGs on the node? 14:16:31 <ralonsoh> no no 14:16:39 <ralonsoh> those are different FWs 14:16:56 <ralonsoh> same as the two drivers we have for OVS right now 14:16:59 <ralonsoh> we can't mix both 14:17:31 <ralonsoh> what Liu needs, and I understand, is not to use CT 14:17:52 <ralonsoh> but as I said, you can create a plugin project and create this entry point 14:17:55 <ralonsoh> and use it 14:18:44 <obondarev> not sure I understand what is plugin project in this context 14:18:51 <slaweq> ok, so IIUC if we will have such new driver, and someone will configure it on the compute node, all SG on that node will be stateless 14:18:51 <lajoskatona1> outside of Neutron tree? 14:18:53 <slaweq> correct? 14:18:54 <mlavalle> me neither 14:19:40 <ralonsoh> slaweq, the backend implementation will be stateless, because the FW uses learn actions, not CR 14:19:48 <ralonsoh> lajoskatona1, yes, in another project 14:19:50 <ralonsoh> lajoskatona1, https://github.com/openstack-archive/networking-ovs-dpdk/blob/stable/ocata/networking_ovs_dpdk/agent/ovs_dpdk_firewall.py 14:19:53 <ralonsoh> ^^ for example 14:20:21 <lajoskatona1> s/CR/CT/ I suppose 14:20:28 <mlavalle> why in another project? 14:20:40 <ralonsoh> mlavalle, not to have it in Neutron 14:20:51 <ralonsoh> actually when I requested this 5 years ago 14:20:56 <ralonsoh> it was rejected 14:21:12 <ralonsoh> because the statefull FW was being implemented 14:21:24 <ralonsoh> this is why I pushed it in networking-ovn-dpdk 14:21:26 <mlavalle> well, but now the case seems to be more compelling. HW offload is a new reason, isn't it? 14:21:37 <ralonsoh> it was before with DPDK 14:21:40 <ralonsoh> this is the same case 14:21:52 <ralonsoh> and CT works with HW offload 14:22:02 <ralonsoh> anyway, I won't reject this proposal 14:22:12 <lajoskatona1> Yeah why cant we have it in a floder like this : https://opendev.org/openstack/neutron/src/branch/master/neutron/agent/linux/openvswitch_firewall ? opensvswitch_stateless_fw 14:22:18 <mlavalle> I also think it is a good proposal 14:22:25 <ralonsoh> I'm just devil's advocate here 14:22:43 <mlavalle> I just don;t understand why not have it in Neutron 14:23:00 <obondarev> ralonsoh: do you agree it should not be a separate driver? 14:23:07 <mlavalle> Maybe there is a reason that I don't know, I just want to understand why 14:23:12 <amotoki> ovs-dpdk implementation is to support DPDK, so I guess it was implemented from a bit different need. 14:23:14 <lajoskatona1> +1 14:23:29 <ralonsoh> amotoki, no 14:23:48 <ralonsoh> that fw driver was implemented because DPDK didn't support CT at this point 14:23:55 <mlavalle> lajoskatona1: yes, that is what I also want to understand 14:24:09 <ralonsoh> but works fine with kernel OVS 14:24:27 <amotoki> ralonsoh: thanks. sounds fair 14:25:42 <ralonsoh> to be honest, I'm not against having this FW in the neutron code 14:25:49 <ralonsoh> as I requested 5 years ago 14:25:54 <ralonsoh> the point is: 14:26:17 <ralonsoh> 1) we need to implement it isolated to the rest of the code 14:26:32 <ralonsoh> 2) we should have proper testing (another CI job running with OVS) 14:27:17 <ralonsoh> 3) should be properly documented with the limitations (it won't scale well with remote groups because it does not uses CT groups) 14:27:25 <ralonsoh> OF groups, sorry 14:27:42 <slaweq> nothing scales well with remote groups ;) 14:27:43 <ralonsoh> OF conjuntions (sorry!!!) 14:27:47 <ralonsoh> slaweq, yeah... 14:27:53 <mlavalle> slaweq: LOL 14:28:04 <ralonsoh> so, with those 3 conditions, +1 14:28:58 <lajoskatona1> ok so if new driver is needed the stateful field is useless for this driver, as it decided on deployment time, am I right? 14:29:33 <amotoki> I wonder what is the assumption of the stateless SG implementation. stateful and stateless FW can co-exist on a single node? what about the iptable firewall situtaion? 14:29:34 <ralonsoh> right 14:29:43 <obondarev> why need a separate CI? Couldn't we just add tests for stateless SGs to existing job? 14:29:44 <ralonsoh> amotoki, no 14:29:55 <ralonsoh> you can't use more that one FW in a node 14:30:36 <obondarev> ralonsoh: I thought we can.. what's the limitation? 14:31:02 <slaweq> obondarev: how if that would be another driver? then You need to set it up on in the devstack 14:31:05 <obondarev> I thought the difference is in OF flows only 14:31:19 <lajoskatona1> and in this case that can be confuing inf one node has ovs the other ovs_stateless, and behaves differently based on scheduling decision 14:31:38 <ralonsoh> obondarev, no no, not the OF flows only. This is a completely different driver 14:31:49 <ralonsoh> this is not an extension of the current OF FW 14:31:53 <obondarev> ralonsoh: ok got it, thanks 14:32:11 <ralonsoh> in any case, maybe Liu has something else in mind 14:32:27 <obondarev> so I believe we need a spec :) 14:32:33 <lajoskatona1> +1 14:32:41 <ralonsoh> (but that's what I understood last day, that this was going to be another FW driver) 14:32:43 <amotoki> ralonsoh: so you are just talkinag about networing-ovs-dpdk dirver? 14:32:55 <mlavalle> so why don't we approve this RFE, request a spec and hash out these lingering questions in the spec? 14:33:02 <ralonsoh> amotoki, yes because this is what Liu wants to implement in Neutron 14:33:11 <ralonsoh> mlavalle, perfect for me 14:33:40 <amotoki> ralonsoh: got it. I am wondering how we can support it theoretically in OVS firewall. 14:34:18 <ralonsoh> amotoki, I wouldn't touch the current OVS FW to add this support 14:34:19 <lajoskatona1> ok, than I add rfe approved tag in LP, and attach this dicsussion and ask for a spec, is that ok for everybody? 14:34:29 <ralonsoh> +1 14:34:50 <slaweq> +1 14:35:11 <amotoki> +1. there is no reason to reject it but we need a spec to clarify the detail 14:35:12 <mlavalle> +1 obviously 14:36:25 <lajoskatona1> njohnston: Your opinion? 14:37:11 <njohnston> +1 I think the spec will make things clearer but I think it is really a good idea 14:37:22 <lajoskatona1> ok, thanks :-) 14:37:47 <lajoskatona1> ok, we have an agreement, and Liu can start working on it based on this 14:38:13 <lajoskatona1> We have no other topic for today, Do you have perhaps more things to discuss? 14:39:21 <mlavalle> I don't 14:39:28 <slaweq> me neighter 14:39:33 <amotoki> none from me 14:39:50 <ralonsoh> I don't 14:39:51 <lajoskatona1> Ok, Thanks for the discussion, have a nice weekend 14:39:58 <lajoskatona1> #endmeeting