| *** gmann is now known as gmann_afk | 00:07 | |
| *** gmann_afk is now known as gmann | 01:11 | |
| opendevreview | yangjianfeng proposed openstack/neutron master: Improve Router callback system's publish events https://review.opendev.org/c/openstack/neutron/+/804846 | 04:10 |
|---|---|---|
| opendevreview | yangjianfeng proposed openstack/neutron master: [Server Side] L3 router support ndp proxy https://review.opendev.org/c/openstack/neutron/+/743142 | 04:38 |
| opendevreview | yangjianfeng proposed openstack/neutron master: [WIP][PoC][Agent Side] L3 router support ndp proxy https://review.opendev.org/c/openstack/neutron/+/744815 | 04:44 |
| opendevreview | Manu B proposed openstack/neutron-dynamic-routing master: * Status update https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/811300 | 05:08 |
| opendevreview | Manu B proposed openstack/neutron-dynamic-routing master: Status update https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/811300 | 06:50 |
| *** frickler_ is now known as frickler | 07:25 | |
| bcafarel | lajoskatona: just dropping l-c should be enough for xena no? or are they needed l-c constraints we missed before? | 07:26 |
| lajoskatona | bcafarel: true, I always forgot that we we can drop (with bleeding heart) l-c job | 07:29 |
| bcafarel | :) | 07:29 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/xena: Execute the quota reservation removal in an isolated DB txn https://review.opendev.org/c/openstack/neutron/+/811124 | 07:40 |
| opendevreview | Lajos Katona proposed openstack/python-neutronclient master: Add BFD monitor commands to client https://review.opendev.org/c/openstack/python-neutronclient/+/812101 | 07:46 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Remove SubnetDNSPublishFixedIP from Subnet query https://review.opendev.org/c/openstack/neutron/+/811999 | 08:03 |
| opendevreview | Lajos Katona proposed openstack/neutron-vpnaas stable/xena: [stable/xena] Dropping lower-constraints testing https://review.opendev.org/c/openstack/neutron-vpnaas/+/812104 | 08:06 |
| opendevreview | Balazs Gibizer proposed openstack/neutron master: Enable min pps tempest tests https://review.opendev.org/c/openstack/neutron/+/811746 | 08:11 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron-vpnaas stable/train: Pin isort to 4.3.21 https://review.opendev.org/c/openstack/neutron-vpnaas/+/805969 | 08:15 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Fix "_sync_metadata_ports" with no DHCP subnets https://review.opendev.org/c/openstack/neutron/+/811996 | 08:44 |
| opendevreview | Merged openstack/neutron master: [DVR] Check if SNAT iptables manager is initialized https://review.opendev.org/c/openstack/neutron/+/811318 | 08:56 |
| opendevreview | Lajos Katona proposed openstack/neutron master: Doc: prerelease checklist https://review.opendev.org/c/openstack/neutron/+/812112 | 09:26 |
| ralonsoh | lajoskatona, slaweq https://5ee086437c476c5dcb72-8ecfd22b203beab683094d725f2cb9f1.ssl.cf2.rackcdn.com/809983/7/check/neutron-tempest-plugin-scenario-linuxbridge/371b3dd/controller/logs/syslog.txt | 10:01 |
| ralonsoh | checking the logs (of the https://review.opendev.org/c/openstack/neutron/+/809983 patch) | 10:01 |
| ralonsoh | we still have OOM errors | 10:02 |
| slaweq | ralonsoh: yes, I think we are still waiting for gmann's changes in tempest | 10:03 |
| ralonsoh | perfect then | 10:04 |
| slaweq | so we will be able to run tests whch needs advanced image serially | 10:04 |
| slaweq | after other tests will be finished | 10:04 |
| ralonsoh | yeah | 10:04 |
| slaweq | that way we should use less memory in same time | 10:04 |
| slaweq | but it requires changes in tempest | 10:04 |
| slaweq | I didn't check recently how it is now | 10:04 |
| lajoskatona | ralonsoh: this is gmann's patch for serial execution: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/807800 (and it's depends-on patch) | 10:34 |
| ralonsoh | lajoskatona, thanks! | 10:34 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron-vpnaas stable/xena: Update .gitreview for stable/xena https://review.opendev.org/c/openstack/neutron-vpnaas/+/809793 | 10:35 |
| opendevreview | Bernard Cafarelli proposed openstack/neutron-vpnaas stable/xena: Update TOX_CONSTRAINTS_FILE for stable/xena https://review.opendev.org/c/openstack/neutron-vpnaas/+/809795 | 10:35 |
| opendevreview | Balazs Gibizer proposed openstack/neutron master: Enable min pps tempest tests https://review.opendev.org/c/openstack/neutron/+/811746 | 10:48 |
| lajoskatona | bcafarel, slaweq: I added a new line to release checklist: https://review.opendev.org/c/openstack/neutron/+/812112 . Check it please if we need it or not, when you have few mins | 11:27 |
| bcafarel | lajoskatona: sure I will look after lunch! | 11:39 |
| slaweq | lajoskatona: sure | 11:40 |
| opendevreview | Przemyslaw Szczerbik proposed openstack/python-neutronclient master: Add support for minimum packet rate rule to the client https://review.opendev.org/c/openstack/python-neutronclient/+/812132 | 13:03 |
| ralonsoh | lajoskatona, slaweq https://review.opendev.org/c/openstack/neutron/+/809983 what do you think? So we merge it? CI is passing (after 7 rechecks) | 13:12 |
| ralonsoh | stable/xena is passing too | 13:12 |
| lajoskatona | ralonsoh: I wf+1-d the master one | 13:14 |
| ralonsoh | thanks | 13:15 |
| lajoskatona | ralonsoh: we waited and rechecked enough to include it :-) Thanks | 13:15 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Fix binding:profile parameter type check in the API https://review.opendev.org/c/openstack/neutron/+/811971 | 13:26 |
| gmann | slaweq: ralonsoh lajoskatona ah yeah, could not finish that as other gate blocker came. But I will continue this next week. | 13:56 |
| lajoskatona | gmann: thanks, if you are overloaded I can take it over | 13:57 |
| mlavalle | lajoskatona: the meeting is in this channel, right? | 13:57 |
| lajoskatona | malavalle: yes | 13:57 |
| gmann | lajoskatona: let me try next week which should be not overloaded unless we hit another bugs. I will let you know | 13:57 |
| lajoskatona | gmann: ok | 13:57 |
| slaweq | lajoskatona: do we have drivers meeting now? | 14:01 |
| slaweq | are You going to start it? | 14:01 |
| ralonsoh | hi | 14:02 |
| ralonsoh | gmann, thanks | 14:02 |
| slaweq | ralonsoh: mlavalle and others, as we are waiting for lajoskatona with drivers meeting I will ask You if You can maybe add to Your review list my two specs https://review.opendev.org/c/openstack/neutron-specs/+/810822 and https://review.opendev.org/c/openstack/neutron-specs/+/798704 | 14:07 |
| slaweq | thx in advance | 14:07 |
| lajoskatona1 | #startmeeting neutron_drivers | 14:07 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:07 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:07 |
| lajoskatona1 | Sorry, I disappeared without notice from the channel... | 14:07 |
| mlavalle | seems lajoskatona is having problems with his connection | 14:07 |
| ralonsoh | hi | 14:07 |
| mlavalle | o/ | 14:07 |
| slaweq | o/ | 14:07 |
| lajoskatona1 | Hi | 14:07 |
| amotoki | o/ | 14:07 |
| njohnston | o/ | 14:08 |
| lajoskatona1 | So we have only on etopic for today which is stateless firewall for OVS: https://bugs.launchpad.net/neutron/+bug/1885261 | 14:08 |
| 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 |
| obondarev | hi | 14:09 |
| 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:10 |
| slaweq | I don't think it would be good to keep it as new driver | 14:11 |
| slaweq | in case of iptables_hybrid it's the same driver still | 14:11 |
| slaweq | and can do both stateless and stateful SGs | 14:12 |
| lajoskatona1 | Some administratie question: do we need a spec for it? personally I think it's not necessary | 14:12 |
| slaweq | IIRC | 14:12 |
| lajoskatona1 | yes for that we have a new API field, that can be used now as well | 14:12 |
| obondarev | +1 for no need new driver | 14:13 |
| 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 |
| slaweq | regarding spec IMVHO we should have something what will describe how flows will be done in that case | 14:13 |
| njohnston | +1 agree with slaweq | 14:13 |
| slaweq | it don't need to be spec, but maybe good documentation together with code should be required | 14:13 |
| lajoskatona1 | ok | 14:13 |
| mlavalle | docs are always good | 14:14 |
| slaweq | and now I would like to ask ralonsoh about how hard it can be to make it working :) | 14:14 |
| ralonsoh | both FW drivers are differents, this is not mixing stateless and stateful rules | 14:14 |
| slaweq | as he worked on something like that in the past probably | 14:14 |
| ralonsoh | this is like openswitch and hybrid | 14:14 |
| ralonsoh | so the point here is to have another driver | 14:14 |
| ralonsoh | but you can always create a plugin and create an entry point | 14:15 |
| ralonsoh | as in networking-ovs-dpdk | 14:15 |
| ralonsoh | (this is the FW liu's wants to re-implement) | 14:15 |
| lajoskatona1 | ok, so your point is that we cant mix and select on the fly? | 14:16 |
| 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 |
| ralonsoh | no no | 14:16 |
| ralonsoh | those are different FWs | 14:16 |
| ralonsoh | same as the two drivers we have for OVS right now | 14:16 |
| ralonsoh | we can't mix both | 14:16 |
| ralonsoh | what Liu needs, and I understand, is not to use CT | 14:17 |
| ralonsoh | but as I said, you can create a plugin project and create this entry point | 14:17 |
| ralonsoh | and use it | 14:17 |
| obondarev | not sure I understand what is plugin project in this context | 14:18 |
| 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 |
| lajoskatona1 | outside of Neutron tree? | 14:18 |
| slaweq | correct? | 14:18 |
| mlavalle | me neither | 14:18 |
| ralonsoh | slaweq, the backend implementation will be stateless, because the FW uses learn actions, not CR | 14:19 |
| ralonsoh | lajoskatona1, yes, in another project | 14:19 |
| ralonsoh | lajoskatona1, https://github.com/openstack-archive/networking-ovs-dpdk/blob/stable/ocata/networking_ovs_dpdk/agent/ovs_dpdk_firewall.py | 14:19 |
| ralonsoh | ^^ for example | 14:19 |
| lajoskatona1 | s/CR/CT/ I suppose | 14:20 |
| mlavalle | why in another project? | 14:20 |
| ralonsoh | mlavalle, not to have it in Neutron | 14:20 |
| ralonsoh | actually when I requested this 5 years ago | 14:20 |
| ralonsoh | it was rejected | 14:20 |
| ralonsoh | because the statefull FW was being implemented | 14:21 |
| ralonsoh | this is why I pushed it in networking-ovn-dpdk | 14:21 |
| mlavalle | well, but now the case seems to be more compelling. HW offload is a new reason, isn't it? | 14:21 |
| ralonsoh | it was before with DPDK | 14:21 |
| ralonsoh | this is the same case | 14:21 |
| ralonsoh | and CT works with HW offload | 14:21 |
| ralonsoh | anyway, I won't reject this proposal | 14:22 |
| 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 |
| mlavalle | I also think it is a good proposal | 14:22 |
| ralonsoh | I'm just devil's advocate here | 14:22 |
| mlavalle | I just don;t understand why not have it in Neutron | 14:22 |
| obondarev | ralonsoh: do you agree it should not be a separate driver? | 14:23 |
| mlavalle | Maybe there is a reason that I don't know, I just want to understand why | 14:23 |
| amotoki | ovs-dpdk implementation is to support DPDK, so I guess it was implemented from a bit different need. | 14:23 |
| lajoskatona1 | +1 | 14:23 |
| ralonsoh | amotoki, no | 14:23 |
| ralonsoh | that fw driver was implemented because DPDK didn't support CT at this point | 14:23 |
| mlavalle | lajoskatona1: yes, that is what I also want to understand | 14:23 |
| ralonsoh | but works fine with kernel OVS | 14:24 |
| amotoki | ralonsoh: thanks. sounds fair | 14:24 |
| ralonsoh | to be honest, I'm not against having this FW in the neutron code | 14:25 |
| ralonsoh | as I requested 5 years ago | 14:25 |
| ralonsoh | the point is: | 14:25 |
| ralonsoh | 1) we need to implement it isolated to the rest of the code | 14:26 |
| ralonsoh | 2) we should have proper testing (another CI job running with OVS) | 14:26 |
| 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 |
| ralonsoh | OF groups, sorry | 14:27 |
| slaweq | nothing scales well with remote groups ;) | 14:27 |
| ralonsoh | OF conjuntions (sorry!!!) | 14:27 |
| ralonsoh | slaweq, yeah... | 14:27 |
| mlavalle | slaweq: LOL | 14:27 |
| ralonsoh | so, with those 3 conditions, +1 | 14:28 |
| 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:28 |
| 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 |
| ralonsoh | right | 14:29 |
| obondarev | why need a separate CI? Couldn't we just add tests for stateless SGs to existing job? | 14:29 |
| ralonsoh | amotoki, no | 14:29 |
| ralonsoh | you can't use more that one FW in a node | 14:29 |
| obondarev | ralonsoh: I thought we can.. what's the limitation? | 14:30 |
| slaweq | obondarev: how if that would be another driver? then You need to set it up on in the devstack | 14:31 |
| obondarev | I thought the difference is in OF flows only | 14:31 |
| 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 |
| ralonsoh | obondarev, no no, not the OF flows only. This is a completely different driver | 14:31 |
| ralonsoh | this is not an extension of the current OF FW | 14:31 |
| obondarev | ralonsoh: ok got it, thanks | 14:31 |
| ralonsoh | in any case, maybe Liu has something else in mind | 14:32 |
| obondarev | so I believe we need a spec :) | 14:32 |
| lajoskatona1 | +1 | 14:32 |
| ralonsoh | (but that's what I understood last day, that this was going to be another FW driver) | 14:32 |
| amotoki | ralonsoh: so you are just talkinag about networing-ovs-dpdk dirver? | 14:32 |
| mlavalle | so why don't we approve this RFE, request a spec and hash out these lingering questions in the spec? | 14:32 |
| ralonsoh | amotoki, yes because this is what Liu wants to implement in Neutron | 14:33 |
| ralonsoh | mlavalle, perfect for me | 14:33 |
| amotoki | ralonsoh: got it. I am wondering how we can support it theoretically in OVS firewall. | 14:33 |
| ralonsoh | amotoki, I wouldn't touch the current OVS FW to add this support | 14:34 |
| 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 |
| ralonsoh | +1 | 14:34 |
| slaweq | +1 | 14:34 |
| amotoki | +1. there is no reason to reject it but we need a spec to clarify the detail | 14:35 |
| mlavalle | +1 obviously | 14:35 |
| lajoskatona1 | njohnston: Your opinion? | 14:36 |
| njohnston | +1 I think the spec will make things clearer but I think it is really a good idea | 14:37 |
| lajoskatona1 | ok, thanks :-) | 14:37 |
| lajoskatona1 | ok, we have an agreement, and Liu can start working on it based on this | 14:37 |
| lajoskatona1 | We have no other topic for today, Do you have perhaps more things to discuss? | 14:38 |
| mlavalle | I don't | 14:39 |
| slaweq | me neighter | 14:39 |
| amotoki | none from me | 14:39 |
| ralonsoh | I don't | 14:39 |
| lajoskatona1 | Ok, Thanks for the discussion, have a nice weekend | 14:39 |
| lajoskatona1 | #endmeeting | 14:39 |
| opendevmeet | Meeting ended Fri Oct 1 14:39:58 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:39 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-10-01-14.07.html | 14:39 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-10-01-14.07.txt | 14:39 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-10-01-14.07.log.html | 14:39 |
| slaweq | thx, have a great weekend all | 14:40 |
| ralonsoh | have a nice weekend! | 14:40 |
| slaweq | o/ | 14:40 |
| lajoskatona1 | Bye | 14:40 |
| amotoki | o/ | 14:40 |
| mlavalle | o/ | 14:40 |
| njohnston | o/ | 14:40 |
| seba | I'm trying to get https://review.opendev.org/c/openstack/neutron/+/788714 through the ci, but some zool tasks always fail and it's different tasks. It doesn't seem to explicitly be timeouts, but it also doesn't break consistently. Should I just recheck it again? | 14:46 |
| isabek | seba: Hi! Yes just recheck it. Because this failures not related to patch | 14:49 |
| seba | okay, tnx :) | 14:53 |
| *** tbachman is now known as Guest1503 | 14:54 | |
| opendevreview | Ghanshyam proposed openstack/neutron-vpnaas stable/train: Pin isort to 4.3.21 https://review.opendev.org/c/openstack/neutron-vpnaas/+/805969 | 15:33 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/xena: Allow to set the OpenFlow protocol when needed https://review.opendev.org/c/openstack/neutron/+/812162 | 15:36 |
| opendevreview | Merged openstack/neutron master: Doc: prerelease checklist https://review.opendev.org/c/openstack/neutron/+/812112 | 15:54 |
| *** tbachman is now known as Guest1510 | 16:16 | |
| opendevreview | Elod Illes proposed openstack/neutron-vpnaas master: Replace old UPPER_CONSTRAINTS_FILE name and url https://review.opendev.org/c/openstack/neutron-vpnaas/+/812169 | 16:27 |
| opendevreview | Merged openstack/neutron-vpnaas stable/xena: [stable/xena] Dropping lower-constraints testing https://review.opendev.org/c/openstack/neutron-vpnaas/+/812104 | 16:57 |
| opendevreview | Merged openstack/neutron-vpnaas stable/xena: Update .gitreview for stable/xena https://review.opendev.org/c/openstack/neutron-vpnaas/+/809793 | 16:57 |
| opendevreview | Merged openstack/neutron-vpnaas stable/xena: Update TOX_CONSTRAINTS_FILE for stable/xena https://review.opendev.org/c/openstack/neutron-vpnaas/+/809795 | 16:57 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [WIP] [OVN] Check if OVN NB supports Port_Group https://review.opendev.org/c/openstack/neutron/+/812176 | 17:04 |
| opendevreview | Merged openstack/neutron stable/xena: Execute the quota reservation removal in an isolated DB txn https://review.opendev.org/c/openstack/neutron/+/811124 | 17:52 |
| opendevreview | Merged openstack/neutron master: [OVN] Set NB/SB "connection" inactivity probe https://review.opendev.org/c/openstack/neutron/+/800521 | 17:55 |
| -opendevstatus- NOTICE: The review.opendev.org Gerrit server has become unreachable as of approximately 19:10 UTC due to a networking issue in the provider, but should be reachable again shortly | 19:44 | |
| hberaud | amotoki: o/ Please can you validate https://review.opendev.org/c/openstack/releases/+/811036 | 19:59 |
| hberaud | bcafarel: o/ ^ | 19:59 |
| bcafarel | oh nice the xena backport merged for that quota reservation one (master will need another recheck) | 20:05 |
| hberaud | once neutron's RC2 will be out we will proceed the final release for all the RC deliverables | 20:08 |
| bcafarel | hberaud: ack, looks good to go for me at least | 20:10 |
| hberaud | thanks | 20:11 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!