Tuesday, 2025-05-06

opendevreviewBrian Haley proposed openstack/neutron master: Allow service role more RBAC access for Octavia  https://review.opendev.org/c/openstack/neutron/+/94532900:47
opendevreviewBrian Haley proposed openstack/neutron master: Allow service role more RBAC access for Octavia  https://review.opendev.org/c/openstack/neutron/+/94532900:48
cardoemlavalle: ah I see. sometimes when I restart neutron it's making the router on OVN during the startup of neutron. I'm guessing when its syncing the DB?01:24
opendevreviewMerged openstack/neutron stable/2024.2: Subnet filter by "router:external" needs to be changed to "external"  https://review.opendev.org/c/openstack/neutron/+/94878005:10
opendevreviewMerged openstack/neutron master: [ovn]Allow multiple IPv6 ports on router from same network  https://review.opendev.org/c/openstack/neutron/+/93693105:10
opendevreviewliuyulong proposed openstack/neutron master: Revert "Synchronize the network segment range initialization"  https://review.opendev.org/c/openstack/neutron/+/94781205:58
opendevreviewliuyulong proposed openstack/neutron master: Adds unique constraint for network segment ranges  https://review.opendev.org/c/openstack/neutron/+/94789805:58
ykarelthx ralonsoh for reporting https://bugs.launchpad.net/bugs/2110004, i was about to report that06:01
ralonsohykarel, yw!06:01
sahido/07:27
tobias-urdincan i get another +2 core review on https://review.opendev.org/c/openstack/neutron/+/945329 – thx!08:09
ralonsohlet me check08:10
ralonsohslaweq, ^ can you review it a last time? This is RBAC related08:12
hamidlotfi__Hi there,08:28
hamidlotfi__I'm using Neutron FWaaS v2 with OpenStack 2024.1 deployed via kolla-ansible. In an environment with DVR enabled, firewall rules between subnets are not applied as expected. The same configuration works correctly in another setup where DVR is disabled.08:28
hamidlotfi__I have two subnets (10.10.10.0/24 and 20.20.20.0/24) connected via a router with DVR enabled, and I’m trying to isolate them using FWaaS v2 rules, but instances can still ping each other.08:28
hamidlotfi__In a separate environment without DVR, the same FWaaS v2 configuration works correctly and blocks the traffic as expected, Any suggestions?08:28
ralonsohhamidlotfi__, if I recall correctly, there is a bug about this08:37
ralonsohno, is about bgp08:37
ralonsohbut I think it could be related08:38
ralonsohhttps://bugs.launchpad.net/neutron/+bug/210763408:38
opendevreviewLajos Katona proposed openstack/neutron-tempest-plugin master: Tap Mirror API and scenario tests  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/88600408:51
slaweqralonsoh tobias-urdin approved08:58
opendevreviewLajos Katona proposed openstack/neutron-tempest-plugin master: Remove Bobcat 2023.2 jobs  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/94885008:59
tobias-urdinslaweq: ralonsoh thanks :)09:09
slaweqtobias-urdin thank you for the patch :)09:22
hamidlotfi__ralonsoh: Thanks for your reply. I don't think it's related to BGP because I didn't enable BGP.10:10
ralonsohhamidlotfi__, no, but the issue with the DVR router could be10:12
ralonsohplease check the bug10:12
opendevreviewliuyulong proposed openstack/neutron master: Partially revert "Synchronize the network segment range initialization"  https://review.opendev.org/c/openstack/neutron/+/94781210:12
opendevreviewliuyulong proposed openstack/neutron master: Adds unique constraint for network segment ranges  https://review.opendev.org/c/openstack/neutron/+/94789810:12
opendevreviewMerged openstack/neutron master: Update ``filter_existing_chassis`` signature and make it static  https://review.opendev.org/c/openstack/neutron/+/94732110:17
opendevreviewMerged openstack/neutron master: Allow service role more RBAC access for Octavia  https://review.opendev.org/c/openstack/neutron/+/94532911:21
opendevreviewRodolfo Alonso proposed openstack/neutron master: Initialize the network segment ranges only in first WSGI worker  https://review.opendev.org/c/openstack/neutron/+/94820011:41
haleyb#startmeeting networking13:00
opendevmeetMeeting started Tue May  6 13:00:32 2025 UTC and is due to finish in 60 minutes.  The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot.13:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.13:00
opendevmeetThe meeting name has been set to 'networking'13:00
haleybPing list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, haleyb, ralonsoh13:00
mlavalle\o13:00
lajoskatonao/13:00
mtomaskao/13:00
ralonsohhello13:00
obondarevo/13:00
haleybok let's get started13:01
haleyb#announcements13:01
slaweqo/13:01
haleybWe are currently in Week R-21 of Flamingo13:01
cbuggyo/13:01
haleybFinal 2025.2 Flamingo release: October 3rd, 202513:01
haleyb#link https://releases.openstack.org/flamingo/schedule.html13:02
haleybReminder: If you have a topic for the drivers meeting on Friday, please add it to the wiki @ https://wiki.openstack.org/wiki/Meetings/NeutronDrivers13:02
haleybthat said, I am out this Friday and all next week13:02
rubasovo/13:03
haleybmight be online randomly but at work meeting13:03
haleybif anyone is in Frankfurt i will buy the beers13:03
haleybso i am looking for someone to run this meeting next week, and the drivers if there is an agenda13:04
ralonsohI can do it13:04
haleybthanks ralonsoh!13:05
haleybi had no other announcements, anyone else have something?13:06
slaweqI won't be able to attend drivers meeting this week probably13:06
ralonsohthen we should cancel next drivers meeting13:07
opendevreviewMerged openstack/neutron stable/2025.1: [Stable Only][CI][fips jobs] Use stable constraints for tempest  https://review.opendev.org/c/openstack/neutron/+/94879613:07
haleybsure, will cancel this weeks meeting and cleanup the wiki13:07
haleyb#topic bugs13:08
haleybotherwiseguy was marked as deputy but i never did track him down, but i was watching bugs and there were not many, will just go through the unowned ones13:09
haleyb#link https://bugs.launchpad.net/neutron/+bug/210986513:10
haleybOVN 24.09.0: Router Ports Remain DOWN and Unclaimed in OpenStack (Kolla-Ansible) Deployment13:10
haleybthis is most likely something in the config13:11
mtomaskaAll router ports remain DOWN and are not reachable from DHCP namespaces. Are they using DHCP agent with ML2 OVN?13:11
haleybmtomaska: that's a good question, didn't connect the dots there13:12
haleybthere should only be ovnmeta namespaces13:12
mtomaskaright, but maybe they need DHCP agent for baremetal? that is the only use case I know about dhcp agent + OVN13:13
mtomaskaanyway. Ill ask more Qs13:13
ralonsohI'm checking the CI and I don't think we are yet testing this OVN version13:13
ralonsohin noble, we use the package provided that is 24.03.x13:14
ralonsohand we use other (older) versions in Jammy before13:14
ralonsohbut, and please correct me if I'm wrong, we are not yet testing this version in the CI13:14
ralonsoh(that doesn't mean it should not work)13:14
lajoskatonadon't we have ovn and ovs main jobs?13:15
haleybright, it should work. i can ask if it is a ubuntu-provided OVN as well13:15
ralonsohlajoskatona, yeah... right13:16
ralonsohI'll ask in the bug for logs, in particular when the router and the interfaces are created13:16
haleybralonsoh: ack, thanks13:16
haleybnext one13:17
haleyb#link https://bugs.launchpad.net/neutron/+bug/210959113:17
haleybmaster periodic job running with centos 9-stream broken with py39 constraint drop https://review.opendev.org/c/openstack/requirements/+/94828513:17
haleybykarel picked this up and just pushed a series13:17
mtomaskayatin fixed it https://review.opendev.org/c/openstack/neutron/+/94879613:18
haleybhttps://review.opendev.org/q/topic:%22bug/2109591%2213:18
haleybykarel: so does this mean we can run the centos9 fips job with py3.11 ?13:19
haleyboh maybe yatin is not here13:19
ykarelhaleyb, with those set of patches jobs are green, if those are expected we should be fine13:19
ykarels/expected/accepted13:19
haleybykarel: ack, so then that will allow us to remove py39 from setup.cfg?13:20
ykarelyes13:20
haleyback, can do that when they all merge, thanks!13:21
haleybnext one13:22
haleybthere was another occurence of a possible OVS bug13:23
haleyb#link https://bugs.launchpad.net/neutron/+bug/210967613:23
haleybwhich i marked as a duplicate of13:23
haleyb#link https://bugs.launchpad.net/neutron/+bug/210364113:23
haleyba thread was started on ovs-discuss to try and figure this out13:24
haleybseemed to be a new occurence from the responses13:25
ralonsohI'm not sure about the scenario13:25
ralonsohCreate 2 instances: one uses a VLAN IP, and the other uses Geneve(with floating IP), both same subnet13:25
ralonsohsame subnet? these are 2 different networks (vlan, geneve)13:25
ralonsohI know you have closed the previous bug as duplicated, but maybe the reporter is not subscribed to the new one13:27
ralonsohI'll comment on the closed one13:27
slaweqralonsoh same subnet I guess means that it is same ip address range, like e.g 192.168.1.0/24 in both13:27
haleybit was more about getting vswitchd stuck in the ovs_rcu loop13:27
ralonsohslaweq, yes but then it is using iperf between both13:28
ralonsohand he mentions FIP, so I think there is a router in the middle13:28
slaweqright13:28
ralonsohI'll try to reproduce this scenario13:29
slaweqbut router don't allow to connect overlapping subnets to it13:29
ralonsohthat's the point13:29
slaweqso there is something strange there IMHO13:29
ralonsohahhh the FIP, I think the VLAN VM is in the external network13:30
ralonsohanyway, I'll try to reproduce it13:30
haleybralonsoh: ack, thanks, i can point you at the thread on ovs-discuss if necessary, they had a suggestion if we can reproduce it, i just hadn't had time yet13:31
ralonsohhaleyb, for sure, please, send the link13:31
ralonsohor maybe you can add it in the LP bug too13:31
haleybhttps://mail.openvswitch.org/pipermail/ovs-discuss/2025-April/053586.html13:32
haleybwill add to LP too13:32
haleybi think that was all the new bugs, any others to discuss?13:34
haleybthis week mtomaska is the deputy, next week is bcafarel - is that good for both?13:34
mtomaska ACK13:35
haleybthanks13:35
haleyb#topic community goals13:36
haleyblajoskatona: i noticed your neutronclient change for heat13:36
haleybwas there one for nova as well?13:37
lajoskatonayes, but n time since last tuesday13:37
lajoskatonato check them13:37
lajoskatonaI even have to push this one : https://review.opendev.org/c/openstack/horizon/+/946269 with Horizon folks13:38
haleyback, will take a look!13:38
lajoskatonathanks13:39
haleybralonsoh: did you want to give an update on eventlet patches?13:39
ralonsohno new reviews but this is the progress:13:39
ralonsohI was working on the metadata agent, to replace the socket server13:39
ralonsohand, finally, I realize what is happening13:40
bcafarelhaleyb: late ack, but good for next week!13:40
ralonsohthe new socket server (same as in OVN metadata agent or OVN agent) has a blocking method13:40
haleybbcafarel: thanks!13:40
ralonsohthat doesn't work with eventlet (you need to manually yield)13:41
ralonsohso we need to migrate all the agent in one shot to kernel threads13:41
ralonsohbecause is using oslo.service, I'll push a patch depending on the patch that is under review13:41
ralonsohthat's all (not too much, but took me a lot of time)13:41
haleybthanks for tracking it down, was it causing random CI failures?13:42
ralonsohnot this agent, that I'm aware13:43
ralonsohand all the progress I've done is local (in my computer)13:43
haleybah ok13:43
haleybrelated to eventlet i saw the requirements bump of pyroute2 was reverted since it broke nova (or os-vif?)13:44
ralonsohos-vif, that is the library that uses it in nova-compute13:45
haleybso i think we have to wait13:45
ralonsohyes, Peter is working now with gibi, if I'm not wrong13:45
* gibi perks up13:46
haleyback, and i saw they are making progress on eventlet13:46
haleybgibi: we were just talking about having to revert pyroute2 bump since it broke nova/os-vif13:47
gibiahh yeah at least the maintainer created an issue on pyroute2 to make it work for us13:47
gibiuntil that we pin the deps13:47
gibihttps://github.com/svinota/pyroute2/issues/133813:48
haleyboh, perfect, so we can eventually move to some 0.9-ish pyroute2, perfect13:48
haleybi'll watch the bug thanks for the link13:49
haleyb#topic on-demand13:50
haleybanything else to discuss?13:51
ralonsohI have one topic13:51
haleybsure13:51
ralonsohhttps://bugs.launchpad.net/neutron/+bug/210646313:51
ralonsohthis bug is legit13:51
ralonsohsince we moved to WSGI, there is a problem with the network segment ranges initialization13:52
ralonsohso we can end with duplicated default registers13:52
ralonsohthere are two approaches13:52
ralonsohLiu is pushing this: https://review.opendev.org/c/openstack/neutron/+/94789813:52
ralonsohthat implies to modify the physnet field13:52
ralonsohjust to be clear: in the Neutron code, if physnet is None, we usually declare this a a tunnelled netwokr13:53
ralonsohalso this change is not backportable13:53
ralonsohmy change: https://review.opendev.org/c/openstack/neutron/+/94820013:53
ralonsohis backportable, doesn't need the revert of the code, is WSGI friendly (it moves the initialization to worker=1) and wraps the initialization code inside a DB context13:54
ralonsohif two servers are starting at the same time, this will be DB safe13:54
ralonsohthat's all, is up to you to decide what implementation is better13:55
haleybi remember reviewing this last night but seems you've updated, i think it looks good13:56
ralonsohyes, to add the initialization wrap13:56
ralonsohso all DB calls will be pushed in the same txn13:56
mlavalleI'll review both. I also think it would be a good idea to give him some time to respond to your latest explanation in response to his comment13:56
ralonsohfor sure, this is why I raise this topic13:57
ralonsohraised*13:57
mlavalle+113:57
haleybmlavalle: sure, i will look but only +1 until liu has commented13:57
mlavalleyeap, let's try to get to a consesnsus13:57
haleybalright, we are near top of hour, any other topics?13:58
haleybok, good luck next week, reach out via email if there is a fire while i'm away13:59
haleyb#endmeeting13:59
opendevmeetMeeting ended Tue May  6 13:59:50 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)13:59
opendevmeetMinutes:        https://meetings.opendev.org/meetings/networking/2025/networking.2025-05-06-13.00.html13:59
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/networking/2025/networking.2025-05-06-13.00.txt13:59
opendevmeetLog:            https://meetings.opendev.org/meetings/networking/2025/networking.2025-05-06-13.00.log.html13:59
mlavalle\o13:59
mtomaskao/13:59
ralonsohbye13:59
lajoskatonaBye, have a good travel :-)14:00
haleybthanks, i'll fix all the bugs i can by friday :)14:00
opendevreviewMerged openstack/neutron master: [OVN] Method to retrieve the LRP chassis list  https://review.opendev.org/c/openstack/neutron/+/94778314:03
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] Change the OVN QoS rule priority for floating IPs  https://review.opendev.org/c/openstack/neutron/+/94889414:42
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] Change the OVN QoS rule priority for floating IPs  https://review.opendev.org/c/openstack/neutron/+/94889415:06
opendevreviewLajos Katona proposed openstack/neutron-vpnaas master: [S-RBAC] New default API policies for neutron-vpnaas  https://review.opendev.org/c/openstack/neutron-vpnaas/+/94891416:18
opendevreviewsean mooney proposed openstack/os-vif master: add pyproject.toml to support pip 23.1  https://review.opendev.org/c/openstack/os-vif/+/89994616:27
stephenfinlajoskatona: ralonsoh: Would you be able to take over https://review.opendev.org/c/openstack/devstack/+/932203 and the patch below? You are of course free to abandon in favour of your own patches if needed16:33
opendevreviewRico Lin proposed openstack/neutron master: Fix ovn db sync with log resources  https://review.opendev.org/c/openstack/neutron/+/94805316:48
opendevreviewRico Lin proposed openstack/neutron master: Update instead of recreate acl in ovn sync  https://review.opendev.org/c/openstack/neutron/+/94821516:48
cardoemlavalle: I created https://bugs.launchpad.net/neutron/+bug/2110060 for the issue I saw16:57
opendevreviewMerged openstack/neutron stable/2024.1: [Stable Only][CI][fips jobs] Use stable constraints for tempest  https://review.opendev.org/c/openstack/neutron/+/94880717:09
noonedeadpunkhey there! I'm very sorry, but is there any chance to merge this bugfix? https://review.opendev.org/c/openstack/neutron/+/93149517:56
noonedeadpunkas it's already half a year since last negative comment on it17:57
mlavallecardoe: thank you. Yesterday, when I saw your comment, I suspected that if we indeed had an issue, it would have to do with a maintenance task or restart18:02
mlavallecardoe: I'll take a look at the LP bug18:02
cardoeI'm running 2024.2 fwiw.18:03
mlavallecardoe: ack18:03
opendevreviewMerged openstack/os-vif master: add pyproject.toml to support pip 23.1  https://review.opendev.org/c/openstack/os-vif/+/89994620:48
opendevreviewMaor Blaustein proposed x/whitebox-neutron-tempest-plugin master: Actively check type instead of `WB_CONF.openstack_type`  https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/94795721:17
opendevreviewMaor Blaustein proposed x/whitebox-neutron-tempest-plugin master: Add WSGI check for devstack  https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/94895321:17
opendevreviewsean mooney proposed openstack/neutron master: add pyproject.toml to support pip 23.1  https://review.opendev.org/c/openstack/neutron/+/89995623:07
opendevreviewsean mooney proposed openstack/neutron master: add pyproject.toml to support pip 23.1  https://review.opendev.org/c/openstack/neutron/+/89995623:16

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!