13:00:27 <haleyb> #startmeeting networking
13:00:27 <opendevmeet> Meeting started Tue Sep 23 13:00:27 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:27 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:27 <opendevmeet> The meeting name has been set to 'networking'
13:00:28 <haleyb> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, haleyb, ralonsoh, sahid
13:00:36 <mlavalle> \o
13:00:40 <ralonsoh> hello
13:01:08 <cbuggy> o/
13:01:21 <haleyb> hi everyone
13:01:25 <lajoskatona> o/
13:01:34 <rubasov> o/
13:01:38 <haleyb> #announcements
13:01:43 <haleyb> We are currently in Week R-1 of Flamingo
13:02:00 <haleyb> September 26th, 2025 is the deadline for final 2025.2 "Flamingo" release candidates
13:02:15 <bcafarel> o/
13:02:21 <haleyb> We will then enter a quiet period until we tag the final release on October 1st, 2025
13:02:31 <haleyb> Teams should be prioritizing fixing release-critical bugs, before that deadline
13:03:00 <haleyb> I have not seen any changes that require another RC tag, please ping me if there is one
13:03:11 <haleyb> Reminder: Release blockers will need to be merged to master, then cherry-picked to stable/2025.2
13:03:54 <haleyb> Otherwise it's time to start planning the 2026.1 "Gazpacho" development cycle
13:04:08 <haleyb> The next OpenInfra PTG will take place October 27-31, 2025 and registration for the event is now open
13:04:15 <haleyb> #link https://ptg.openinfra.dev/
13:04:49 <haleyb> hopefully people have signed-up
13:05:28 <haleyb> please start thinking of any topics you want to discuss
13:05:44 <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:06:00 <haleyb> And continue to use the priorities dashboard for important changes or things ready to merge, think there are a few there
13:06:50 <haleyb> there are some topics for this friday's meeting hopefully we have quorum
13:06:59 <haleyb> that was all announcements, anything else?
13:07:16 <mtomaska> o/ question from me
13:07:24 <haleyb> sure
13:07:54 <mtomaska> In regards to this https://review.opendev.org/c/openstack/python-neutronclient/+/960846 patch. I would like to move the tapas OSC client to to the openstackclient repo
13:08:52 <haleyb> mtomaska: that was going to be a discussion at the ptg, since there are a number of things on neutronclient to move
13:08:52 <mtomaska> I see it was discussed on Sept 12 in drivers meeting, but it was not clear to me if there is anything blocking us moving it to the openstackclient repo.
13:08:53 <lajoskatona> We discussed this topic on a previous drivers meeting, so I think you can move the code
13:09:21 <mtomaska> ACK, I will start moving it then. Thank you!
13:09:25 <ralonsoh> so it would be preferable to move any CLI code to OSC
13:09:34 <haleyb> mtomaska: if you want to take ownership of that it would be great
13:09:38 <lajoskatona> Till we have no release I think not much review can be expected for new things
13:10:21 <lajoskatona> yeah thanks for jumping in to this topic
13:10:30 <ralonsoh> haleyb, I think mtomaska will handle it, for sure
13:10:36 <mtomaska> yes :)
13:10:41 <haleyb> perfect :)
13:10:54 <mtomaska> thanks all, that is all from me
13:11:15 <haleyb> ok, moving on
13:11:17 <haleyb> #topic bugs
13:11:26 <haleyb> rubasov was the deputy last week, his report is at
13:11:33 <haleyb> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/ILBNVTADPGM4TA5NDJIJZZ3DGV4K62MU/
13:11:55 <haleyb> we can go through the unassigned
13:12:14 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2124254
13:12:16 <haleyb> [L3] A router with multiple GW ports, if the first is deleted, the GW info is empty
13:12:28 <ralonsoh> yeah, the behaviour is weird
13:12:46 <ralonsoh> if you add GW1, then GW2 and then remove GW1, the GW info of the router is empty
13:12:52 <ralonsoh> but we still have GW2 present
13:13:07 <ralonsoh> so this is a router with one single GW and should be present there
13:13:29 <haleyb> right, seems related to the multiple gw code
13:13:32 <ralonsoh> I provided the steps (4)
13:13:36 <ralonsoh> yes it is
13:14:32 <haleyb> fnordahl: can you look at https://bugs.launchpad.net/neutron/+bug/2124254 just to confirm what should be happening when you remove one GW from a router? maybe it's something we forgot to add a test for
13:14:59 <ralonsoh> (if not, maybe next week I can take it, but not right now)
13:15:03 <haleyb> i can loop back with frode later as he might be busy
13:15:08 <ralonsoh> and this is a candidate to be backported, for sure
13:15:42 <haleyb> yes, maybe one of us here can take it possibly too
13:16:15 <haleyb> next one
13:16:18 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2124269
13:16:24 <haleyb> Can't bind an HA router_gateway port to chassis
13:16:30 <haleyb> i see there were some comments
13:16:57 <ralonsoh> yeah, rubasov is correct there: we use gateway_chassis for LRP, not ha_chassis_group
13:17:05 <ralonsoh> but the other problem is the exception in the logs
13:17:12 <rubasov> I just changed that to incomplete
13:17:15 <ralonsoh> I requested the steps to reproduce it
13:17:25 <rubasov> we need more info as Rodolfo wrote
13:17:40 <ralonsoh> and the other point here is if he defined correctly the GW chassis
13:17:46 <ralonsoh> (also commented in c#3)
13:18:15 <ralonsoh> "I don't care about this feature, I just want my routers to work."
13:18:17 <haleyb> ack, will follow to see comments
13:18:22 <ralonsoh> ^^ I love this sentece
13:19:13 <haleyb> we all want our routers to work :)
13:20:16 <haleyb> next one
13:20:20 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2123848
13:20:27 <haleyb> [ovn-octavia-provider] Octavia LB not reachable with custom firewall appliance
13:21:47 <haleyb> i see froyo asked to contact OVN core team, but there was an additional comment
13:22:06 <haleyb> he must be back from leave to take a look?
13:22:47 <ralonsoh> yes he is back
13:23:03 <rubasov> I hope he can look again because that was above my level of understanding octavia with ovn
13:23:31 <haleyb> i'll assume he is watching as he commented last week, will leave a response to him then
13:23:32 <rubasov> I just marked it incomplete instead
13:24:11 <haleyb> great, thanks
13:24:32 <haleyb> the last two were marked invalid, and we can cover the RFE ones friday
13:24:37 <haleyb> any other bugs to discuss?
13:25:14 <haleyb> mlavalle is the bug deputy this week, lajoskatona next week - that good for both?
13:25:30 <lajoskatona> Yes, I am prepared :-)
13:25:34 <mlavalle> ok with me
13:25:51 <haleyb> great, thanks!
13:26:02 <haleyb> #topic specs
13:26:03 <haleyb> #link https://review.opendev.org/q/project:openstack/neutron-specs+status:open
13:26:12 <haleyb> just a reminder there might be specs in need of review
13:26:45 <haleyb> something i will look at once Flamingo is shipped
13:27:06 <haleyb> #topic community goals
13:27:12 <haleyb> lajoskatona: we can start with neutronclient
13:28:00 <lajoskatona> The only new is that for nova there is the first green patch: https://review.opendev.org/c/openstack/nova/+/928022
13:28:06 <lajoskatona> for networks
13:28:31 <lajoskatona> so I can go to the next thing like subnets or ports
13:29:19 <haleyb> great news! that was a lot of testing changes 8-o
13:30:15 <lajoskatona> yes deeply hardcoded everywhere, so like a n operation :-)
13:31:11 <haleyb> :)
13:31:30 <haleyb> ralonsoh: and i'll let you give status update on eventlet
13:31:40 <ralonsoh> Yeah, I rebased https://review.opendev.org/c/openstack/neutron/+/952258/
13:31:54 <ralonsoh> note: the ovs tempest job failed because of a OOM
13:32:16 <ralonsoh> ^^ please review this patch
13:32:34 <ralonsoh> there are some other patches (lajos is pushing them) to fix other projects
13:32:43 <ralonsoh> https://review.opendev.org/q/topic:%22eventlet-removal%22
13:33:16 <ralonsoh> that's all (I still need to update other patches for Neutron to completely remove eventlet)
13:33:38 <lajoskatona> I have to collect my strength to work on them again
13:33:54 <ralonsoh> I'll review them and push new PS if needed
13:34:18 <haleyb> ralonsoh: ack, thanks for all the work on that, i think my review found mostly nits and some leftover code, otherwise good
13:34:48 <ralonsoh> ++
13:35:34 <haleyb> #topic on-demand
13:35:49 <haleyb> there was one topic from ralonsoh i just forgot to clean wiki to remove older one
13:35:56 <ralonsoh> yeah, one sec
13:35:59 <haleyb> #link https://review.opendev.org/c/openstack/neutron-lib/+/961612
13:36:17 <ralonsoh> So this is related to the multihoming GW for OVN issue
13:36:34 <ralonsoh> I found that we are reviewing the router.enable_snat from the GW information
13:36:45 <ralonsoh> but this is stored in the router table
13:37:05 <ralonsoh> although this is set/defined in the GW API (add_gateway_port, update_gateway_port)
13:37:19 <ralonsoh> and regardless of the number of GWs in a router
13:37:31 <ralonsoh> this flag is unique and global for "router" object
13:37:45 <ralonsoh> ^^ this extension is making it public (as read-only) in the router
13:38:06 <ralonsoh> that's all, that was a justification for this new extension
13:38:31 <haleyb> ralonsoh: so this flag cannot be set during router creation, correct?
13:38:39 <ralonsoh> kind of, let me explain
13:39:01 <ralonsoh> you can do "router create --eanble_snat --external_gateway public router1"
13:39:23 <ralonsoh> that will issue two http requests: one for crouter create, another for GW add (with the flag)
13:39:41 <ralonsoh> if you do "rotuer create --enable_snat router1" that fails because the GW is missing
13:39:56 <ralonsoh> however, the router creation will set the default value
13:40:26 <ralonsoh> I commented that here: https://review.opendev.org/c/openstack/neutron-lib/+/961612/comment/f3164856_ee71b484/
13:41:01 <haleyb> ralonsoh: ack, that explains why the latest PS removed a line from the POST section
13:41:12 <ralonsoh> yes, exactly
13:41:18 <ralonsoh> thanks to slaweq's comment
13:42:21 <haleyb> thanks, will look after meeting
13:42:41 <haleyb> are there any other topics for on-demand?
13:42:51 <mlavalle> haleyb, where are we adding topics for the PTG?
13:43:41 <ralonsoh> I think we can (as we have done before) create our etherpad
13:43:52 <haleyb> mlavalle: last ptg someone created all the etherpads, but i can go create one so we can add topics
13:43:53 <ralonsoh> and then, when the official one is created, move all to this one
13:44:02 <ralonsoh> (we have done this before)
13:44:21 <haleyb> yeah, let me make one
13:44:26 <ralonsoh> ++
13:44:57 <mlavalle> yes, that was really me question. whether we have an etherpad already created
13:46:41 <haleyb> #link https://etherpad.opendev.org/p/oct2025-ptg-neutron
13:46:53 <haleyb> i need to clean it up as i copied from last falls ptg
13:47:07 <mlavalle> thanks haleyb
13:48:07 <haleyb> ok, any other topics?
13:48:10 <lajoskatona> +1
13:48:29 <lajoskatona> no question from me, thanks
13:48:40 <mnaser> i have a nasty race bug that i have a reproducer up for, but i can keep it post meeting :)
13:49:09 <haleyb> mnaser: did you file a bug with the info?
13:49:19 <mnaser> https://bugs.launchpad.net/neutron/+bug/2125500 and a very easy reproducer
13:50:12 <haleyb> oh, 12 minutes ago, which is why it wasn't triaged yet
13:50:29 <mnaser> yes, sorry, got to getting it through this morning once i got a reproducer
13:50:40 <ralonsoh> so you add subnets to a network and a port doesn't receive all IPs??
13:50:52 <ralonsoh> in the OVN DB, I guess, right?
13:50:52 <mnaser> yes, the metadata port specifically
13:51:01 <mnaser> i thought oVN db at first.. but now.. nope, neutron db too :X
13:51:12 <ralonsoh> so in the mysql DB too??
13:51:16 <mnaser> when i wwas playing with this and did 48 subnets, i see 46 fixed_ips in mysql
13:51:21 <mnaser> yep
13:51:29 <ralonsoh> ok, that's a problem, for sure
13:51:34 <ralonsoh> let me check that
13:51:47 <ralonsoh> I'm setting importance to high
13:52:09 <mnaser> thank you, i will spin up a devstack and reproduce in that as well just to try and eliminate factors (maybe galera is doing something funky who knows)
13:52:33 <ralonsoh> but these CLI commands are executed serially
13:52:48 <mnaser> nope, you notice i have an '&' in the for loop
13:52:58 <ralonsoh> ah ah ah
13:53:02 <mnaser> so they actually all get backgrounded and start blasting in parallel in the background
13:53:11 <ralonsoh> how many API workers??
13:53:44 <mnaser> 8 api, 8 rpc X 3
13:53:52 <mnaser> so 3 control plane nodes with 8api/8rpc each
13:53:53 <ralonsoh> ok
13:54:26 <ralonsoh> can you execute that and retrieve the API logs from the 3 controllers??
13:54:29 <ralonsoh> if that is possible
13:54:32 <mnaser> of course
13:54:42 <ralonsoh> if you have sensitive data, please hide it
13:54:52 <mnaser> ill add it to the bug log, might be a bit, yea, there might be noise, so ill try to clear it up :p
13:54:58 <ralonsoh> in debug mode, if possible. That will help us to debug this problem
13:55:16 <haleyb> and i'm assuming running serially is Ok? just slow
13:55:26 <mnaser> well, this user is using heat to bring up these subnets
13:55:48 <mnaser> so serially works fine afaik and is "slow" enough to be ok, but when using heat, it just goes and blasts away and brings this
13:56:04 <haleyb> right
13:56:10 <mnaser> fwiw this issue started at first when they had 48 subnets, i looked at their stuff and said hey, you can make this into like 12 smaller networks with 4 subnets instead
13:56:25 <mnaser> and the issue still occured, but i cannot reproduce it with 4 subnets just via cli myself, so that tells me this is a "under load" thing
13:57:27 <haleyb> ack, thanks, we will take a look
13:57:53 <mnaser> yep, logs coming on up, ill keep digging too if i can get somewhere
13:58:01 <haleyb> anything else? i have a hard stop in :2
13:58:25 <haleyb> #endmeeting