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