13:00:32 <haleyb> #startmeeting networking 13:00:32 <opendevmeet> Meeting 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:32 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:32 <opendevmeet> The meeting name has been set to 'networking' 13:00:34 <haleyb> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, haleyb, ralonsoh 13:00:35 <mlavalle> \o 13:00:37 <lajoskatona> o/ 13:00:43 <mtomaska> o/ 13:00:47 <ralonsoh> hello 13:00:50 <obondarev> o/ 13:01:24 <haleyb> ok let's get started 13:01:27 <haleyb> #announcements 13:01:30 <slaweq> o/ 13:01:43 <haleyb> We are currently in Week R-21 of Flamingo 13:01:47 <cbuggy> o/ 13:01:56 <haleyb> Final 2025.2 Flamingo release: October 3rd, 2025 13:02:03 <haleyb> #link https://releases.openstack.org/flamingo/schedule.html 13:02:12 <haleyb> Reminder: If you have a topic for the drivers meeting on Friday, please add it to the wiki @ https://wiki.openstack.org/wiki/Meetings/NeutronDrivers 13:02:47 <haleyb> that said, I am out this Friday and all next week 13:03:08 <rubasov> o/ 13:03:10 <haleyb> might be online randomly but at work meeting 13:03:37 <haleyb> if anyone is in Frankfurt i will buy the beers 13:04:28 <haleyb> so i am looking for someone to run this meeting next week, and the drivers if there is an agenda 13:04:55 <ralonsoh> I can do it 13:05:19 <haleyb> thanks ralonsoh! 13:06:18 <haleyb> i had no other announcements, anyone else have something? 13:06:41 <slaweq> I won't be able to attend drivers meeting this week probably 13:07:01 <ralonsoh> then we should cancel next drivers meeting 13:07:03 <opendevreview> Merged openstack/neutron stable/2025.1: [Stable Only][CI][fips jobs] Use stable constraints for tempest https://review.opendev.org/c/openstack/neutron/+/948796 13:07:52 <haleyb> sure, will cancel this weeks meeting and cleanup the wiki 13:08:56 <haleyb> #topic bugs 13:09:53 <haleyb> otherwiseguy 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 ones 13:10:04 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2109865 13:10:12 <haleyb> OVN 24.09.0: Router Ports Remain DOWN and Unclaimed in OpenStack (Kolla-Ansible) Deployment 13:11:28 <haleyb> this is most likely something in the config 13:11:45 <mtomaska> All router ports remain DOWN and are not reachable from DHCP namespaces. Are they using DHCP agent with ML2 OVN? 13:12:33 <haleyb> mtomaska: that's a good question, didn't connect the dots there 13:12:49 <haleyb> there should only be ovnmeta namespaces 13:13:31 <mtomaska> right, but maybe they need DHCP agent for baremetal? that is the only use case I know about dhcp agent + OVN 13:13:38 <mtomaska> anyway. Ill ask more Qs 13:13:51 <ralonsoh> I'm checking the CI and I don't think we are yet testing this OVN version 13:14:08 <ralonsoh> in noble, we use the package provided that is 24.03.x 13:14:17 <ralonsoh> and we use other (older) versions in Jammy before 13:14:35 <ralonsoh> but, and please correct me if I'm wrong, we are not yet testing this version in the CI 13:14:43 <ralonsoh> (that doesn't mean it should not work) 13:15:36 <lajoskatona> don't we have ovn and ovs main jobs? 13:15:51 <haleyb> right, it should work. i can ask if it is a ubuntu-provided OVN as well 13:16:03 <ralonsoh> lajoskatona, yeah... right 13:16:21 <ralonsoh> I'll ask in the bug for logs, in particular when the router and the interfaces are created 13:16:28 <haleyb> ralonsoh: ack, thanks 13:17:26 <haleyb> next one 13:17:44 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2109591 13:17:45 <haleyb> master periodic job running with centos 9-stream broken with py39 constraint drop https://review.opendev.org/c/openstack/requirements/+/948285 13:17:57 <haleyb> ykarel picked this up and just pushed a series 13:18:04 <mtomaska> yatin fixed it https://review.opendev.org/c/openstack/neutron/+/948796 13:18:08 <haleyb> https://review.opendev.org/q/topic:%22bug/2109591%22 13:19:17 <haleyb> ykarel: so does this mean we can run the centos9 fips job with py3.11 ? 13:19:46 <haleyb> oh maybe yatin is not here 13:19:50 <ykarel> haleyb, with those set of patches jobs are green, if those are expected we should be fine 13:19:59 <ykarel> s/expected/accepted 13:20:33 <haleyb> ykarel: ack, so then that will allow us to remove py39 from setup.cfg? 13:20:39 <ykarel> yes 13:21:12 <haleyb> ack, can do that when they all merge, thanks! 13:22:50 <haleyb> next one 13:23:25 <haleyb> there was another occurence of a possible OVS bug 13:23:29 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2109676 13:23:33 <haleyb> which i marked as a duplicate of 13:23:44 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2103641 13:24:04 <haleyb> a thread was started on ovs-discuss to try and figure this out 13:25:07 <haleyb> seemed to be a new occurence from the responses 13:25:29 <ralonsoh> I'm not sure about the scenario 13:25:36 <ralonsoh> Create 2 instances: one uses a VLAN IP, and the other uses Geneve(with floating IP), both same subnet 13:25:53 <ralonsoh> same subnet? these are 2 different networks (vlan, geneve) 13:27:08 <ralonsoh> I know you have closed the previous bug as duplicated, but maybe the reporter is not subscribed to the new one 13:27:12 <ralonsoh> I'll comment on the closed one 13:27:52 <slaweq> ralonsoh same subnet I guess means that it is same ip address range, like e.g 192.168.1.0/24 in both 13:27:55 <haleyb> it was more about getting vswitchd stuck in the ovs_rcu loop 13:28:29 <ralonsoh> slaweq, yes but then it is using iperf between both 13:28:42 <ralonsoh> and he mentions FIP, so I think there is a router in the middle 13:28:57 <slaweq> right 13:29:06 <ralonsoh> I'll try to reproduce this scenario 13:29:16 <slaweq> but router don't allow to connect overlapping subnets to it 13:29:29 <ralonsoh> that's the point 13:29:30 <slaweq> so there is something strange there IMHO 13:30:07 <ralonsoh> ahhh the FIP, I think the VLAN VM is in the external network 13:30:17 <ralonsoh> anyway, I'll try to reproduce it 13:31:20 <haleyb> ralonsoh: 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 yet 13:31:36 <ralonsoh> haleyb, for sure, please, send the link 13:31:50 <ralonsoh> or maybe you can add it in the LP bug too 13:32:16 <haleyb> https://mail.openvswitch.org/pipermail/ovs-discuss/2025-April/053586.html 13:32:21 <haleyb> will add to LP too 13:34:22 <haleyb> i think that was all the new bugs, any others to discuss? 13:34:58 <haleyb> this week mtomaska is the deputy, next week is bcafarel - is that good for both? 13:35:04 <mtomaska> ACK 13:35:33 <haleyb> thanks 13:36:26 <haleyb> #topic community goals 13:36:59 <haleyb> lajoskatona: i noticed your neutronclient change for heat 13:37:05 <haleyb> was there one for nova as well? 13:37:41 <lajoskatona> yes, but n time since last tuesday 13:37:43 <lajoskatona> to check them 13:38:13 <lajoskatona> I even have to push this one : https://review.opendev.org/c/openstack/horizon/+/946269 with Horizon folks 13:38:52 <haleyb> ack, will take a look! 13:39:03 <lajoskatona> thanks 13:39:37 <haleyb> ralonsoh: did you want to give an update on eventlet patches? 13:39:47 <ralonsoh> no new reviews but this is the progress: 13:39:58 <ralonsoh> I was working on the metadata agent, to replace the socket server 13:40:11 <ralonsoh> and, finally, I realize what is happening 13:40:30 <bcafarel> haleyb: late ack, but good for next week! 13:40:40 <ralonsoh> the new socket server (same as in OVN metadata agent or OVN agent) has a blocking method 13:40:40 <haleyb> bcafarel: thanks! 13:41:03 <ralonsoh> that doesn't work with eventlet (you need to manually yield) 13:41:14 <ralonsoh> so we need to migrate all the agent in one shot to kernel threads 13:41:34 <ralonsoh> because is using oslo.service, I'll push a patch depending on the patch that is under review 13:41:47 <ralonsoh> that's all (not too much, but took me a lot of time) 13:42:31 <haleyb> thanks for tracking it down, was it causing random CI failures? 13:43:08 <ralonsoh> not this agent, that I'm aware 13:43:32 <ralonsoh> and all the progress I've done is local (in my computer) 13:43:41 <haleyb> ah ok 13:44:43 <haleyb> related to eventlet i saw the requirements bump of pyroute2 was reverted since it broke nova (or os-vif?) 13:45:02 <ralonsoh> os-vif, that is the library that uses it in nova-compute 13:45:02 <haleyb> so i think we have to wait 13:45:19 <ralonsoh> yes, Peter is working now with gibi, if I'm not wrong 13:46:35 * gibi perks up 13:46:38 <haleyb> ack, and i saw they are making progress on eventlet 13:47:08 <haleyb> gibi: we were just talking about having to revert pyroute2 bump since it broke nova/os-vif 13:47:34 <gibi> ahh yeah at least the maintainer created an issue on pyroute2 to make it work for us 13:47:44 <gibi> until that we pin the deps 13:48:40 <gibi> https://github.com/svinota/pyroute2/issues/1338 13:48:42 <haleyb> oh, perfect, so we can eventually move to some 0.9-ish pyroute2, perfect 13:49:39 <haleyb> i'll watch the bug thanks for the link 13:50:57 <haleyb> #topic on-demand 13:51:07 <haleyb> anything else to discuss? 13:51:13 <ralonsoh> I have one topic 13:51:18 <haleyb> sure 13:51:33 <ralonsoh> https://bugs.launchpad.net/neutron/+bug/2106463 13:51:42 <ralonsoh> this bug is legit 13:52:01 <ralonsoh> since we moved to WSGI, there is a problem with the network segment ranges initialization 13:52:09 <ralonsoh> so we can end with duplicated default registers 13:52:19 <ralonsoh> there are two approaches 13:52:37 <ralonsoh> Liu is pushing this: https://review.opendev.org/c/openstack/neutron/+/947898 13:52:55 <ralonsoh> that implies to modify the physnet field 13:53:32 <ralonsoh> just to be clear: in the Neutron code, if physnet is None, we usually declare this a a tunnelled netwokr 13:53:44 <ralonsoh> also this change is not backportable 13:53:55 <ralonsoh> my change: https://review.opendev.org/c/openstack/neutron/+/948200 13:54:36 <ralonsoh> is 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 context 13:54:54 <ralonsoh> if two servers are starting at the same time, this will be DB safe 13:55:40 <ralonsoh> that's all, is up to you to decide what implementation is better 13:56:03 <haleyb> i remember reviewing this last night but seems you've updated, i think it looks good 13:56:17 <ralonsoh> yes, to add the initialization wrap 13:56:28 <ralonsoh> so all DB calls will be pushed in the same txn 13:56:52 <mlavalle> I'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 comment 13:57:09 <ralonsoh> for sure, this is why I raise this topic 13:57:14 <ralonsoh> raised* 13:57:20 <mlavalle> +1 13:57:38 <haleyb> mlavalle: sure, i will look but only +1 until liu has commented 13:57:57 <mlavalle> yeap, let's try to get to a consesnsus 13:58:33 <haleyb> alright, we are near top of hour, any other topics? 13:59:43 <haleyb> ok, good luck next week, reach out via email if there is a fire while i'm away 13:59:50 <haleyb> #endmeeting