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