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