13:00:28 <haleyb> #startmeeting networking 13:00:28 <opendevmeet> Meeting started Tue Jun 10 13:00:28 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:28 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:28 <opendevmeet> The meeting name has been set to 'networking' 13:00:29 <haleyb> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, haleyb, ralonsoh 13:00:30 <mlavalle> \o 13:00:40 <obondarev> o/ 13:00:42 <slaweq> o/ 13:00:47 <ralonsoh> hello 13:00:53 <cbuggy> o/ 13:00:56 <ykarel> o/ 13:01:17 <elvira> hi o/ 13:01:28 <rubasov> o/ 13:02:11 <haleyb> hi everyone, just getting back online after a 4-day weekend, but looks like there weren't too many fires :) 13:02:33 <haleyb> #announcements 13:02:46 <haleyb> We are currently in Week R-15 of Flamingo 13:02:56 <haleyb> Our next milestone in this development cycle will be Flamingo-2, on July 3rd 13:03:03 <haleyb> Final 2025.2 Flamingo release: October 3rd, 2025 13:03:05 <lajoskatona> o/ 13:03:08 <haleyb> #link https://releases.openstack.org/flamingo/schedule.html 13:03:35 <haleyb> and i'll copy a little from the release team email 13:03:44 <haleyb> Please remember that libraries need to be released at least once per milestone period. At milestone 2, the release team will propose releases for any library that has not been otherwise released since milestone 1. 13:03:59 <haleyb> Other non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. 13:04:22 <haleyb> At milestone-2 we also freeze the contents of the final release. If you have a new deliverable that should be included in the final release, you should make sure it has a deliverable file in: 13:04:55 <haleyb> #link https://opendev.org/openstack/releases/src/branch/master/deliverables/flamingo 13:06:05 <haleyb> the other announcement was for the next PTG kickoff 13:06:33 <haleyb> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/FU26JK6VKZNLNK7ZV7SGJF2V4KA37IQW/ 13:06:48 <haleyb> The next OpenInfra PTG[1] will take place October 27-31, 2025 and registration for the event is now open[2]! 13:07:32 <haleyb> I will sign-up neutron for the event 13:08:31 <haleyb> it might conflict with internal travel for me but i will try and work around it 13:09:29 <haleyb> and my final announcement 13:09:33 <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:09:45 <haleyb> i believe we have enough for a meeting this week, will check 13:10:12 <haleyb> oh, one more 13:10:50 <haleyb> kuba sent a doodle to the ML about a face-2-face OVN BGP meeting 13:10:59 <haleyb> #link https://doodle.com/group-poll/participate/aK9Nkknd/vote 13:11:37 <haleyb> if that is of interest please put vote for a time that works for you 13:11:59 <haleyb> looks like the times are early next week 13:12:09 <haleyb> s/early/all 13:12:32 <haleyb> ok, any other announcements? 13:13:07 <haleyb> #topic bugs 13:13:25 <haleyb> i was the deputy last week, just sent an email to the list as i was out 13:13:33 <haleyb> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/SFQT2BEC36MY32DSB6YFVCVJ76KC66O3/ 13:13:51 <opendevreview> Takashi Kajinami proposed openstack/networking-bgpvpn master: Drop explicit dependency on python-subunit https://review.opendev.org/c/openstack/networking-bgpvpn/+/952240 13:14:10 <haleyb> i'll go through the ones without patches 13:14:54 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2112648 13:15:00 <haleyb> [OVS Firewall] Remote-group member flows not restored after port rebind with same IP/MAC during migration to OVS 13:16:04 <lajoskatona> migrating from linuxbridge to OVS? really exotic bug :-) 13:16:13 <haleyb> i marked this High as it checked both the Linuxbridge migration box as well as SGs, although traffic is not flowing 13:16:21 <slaweq> I see there is patch attached to the LP already 13:16:27 <haleyb> lajoskatona: yeah, and i didn't know if it would affect OVN 13:16:38 <haleyb> and yes, there was a patch attached 13:16:40 <slaweq> I think we need to explain this guy how to do it through gerrit instead 13:17:14 <haleyb> slaweq: yes, that was my plan, only saw it this morning 13:17:32 <ralonsoh> I have one question about the cases described were the RPC is not send (I'll ask it in the bug) 13:17:33 <lajoskatona> +1, hard to test anyway, but perhaps available tests catch something or we can ask some test for it 13:17:41 <ralonsoh> this is about 3) The port status appears as DOWN (from the plugin’s view), while the binding status is ACTIVE. 13:18:09 <ralonsoh> if the VM has started, the port should be UP. I would like to know when the port is DOWN if the VM is active 13:18:30 <slaweq> lajoskatona IIUC migraton from LB to OVS has nothing to do with it, 13:19:04 <slaweq> I know he mentioned that in first line of the description but I think it can be reproduced on the "greenfield" ml2/ovs deployment too 13:19:17 <haleyb> "Restarting neutron-openvswitch-agent restores expected flows" 13:19:49 <ralonsoh> haleyb, we refresh all flows, that usually fix every problem we have with the OVS FW 13:20:32 <haleyb> ralonsoh: agreed, this might just be some corner case 13:21:01 <haleyb> let's ask any clarification questions in the bug, and i will suggest they submit a patch 13:22:02 <haleyb> slaweq: and i would agree after reading the migration shouldn't be affecting this 13:22:20 <haleyb> thanks for the discussion, next bug 13:22:26 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2112453 13:22:36 <haleyb> subnet create with subnet-pool and --gateway none creates gateway ip 13:22:57 <haleyb> so this call 13:23:00 <haleyb> $ openstack subnet create --subnet-pool subnetpool --gateway none --network network subnet 13:23:15 <haleyb> i could reproduce on a fresh devstack 13:23:30 <ralonsoh> I can take this one 13:24:20 <haleyb> ralonsoh: ack, thanks - they did mention an older bug you fixed that seemed related, https://bugs.launchpad.net/neutron/+bug/1904436 13:25:00 <ralonsoh> yeah... I'll check the patch I sent 4 years ago 13:25:07 <ralonsoh> (I remember nothing) 13:25:18 <haleyb> :) 13:25:41 <haleyb> next one 13:25:46 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2112492 13:25:52 <haleyb> neutron-metadata-agent shows XXX (dead) status despite being functional in Neutron 26.0.0 13:26:11 <ralonsoh> I had some questions about this 13:26:14 <ralonsoh> C#2 13:26:26 <ykarel> but it looks ovs setup not ovn 13:26:30 <haleyb> right, but i think this was ml2/ovs not ovn 13:26:38 <ralonsoh> this is why I asked that 13:26:40 <ykarel> haleyb, you had q-meta service enabled? 13:26:48 <ralonsoh> I'm not sure what is this folk using 13:26:49 <ykarel> for devstack local setup 13:27:26 <haleyb> ykarel: i could see the agent running but would need to re-stack to verify 13:27:53 <haleyb> i did not have any of the "force" metadata options set to true, which should not have mattered 13:28:14 <haleyb> but 'openstack network agent list' did not even show any metadata agent at all 13:28:20 <ykarel> ack, in my old devstack setup i could see it running and visible in network agent list, triggered restack 13:28:32 <ralonsoh> I have one running now 13:28:34 <ykarel> | 8f50a591-c14d-4425-a5a1-87e7a3dd4aca | Metadata agent | ykarel-dnsovs | None | :-) | UP | neutron-metadata-agent | 13:28:36 <ralonsoh> the agent is alive 13:28:50 <ralonsoh> (running ml2/OVS) 13:29:29 <ralonsoh> maybe we have ask for the agent logs, maybe something is stuck (RPC) 13:29:33 <ykarel> ok then it's all good in master, and issue likely env specific so need logs/configs etc to check further? 13:29:42 <ykarel> yes +1 13:29:44 <ralonsoh> right 13:30:35 <haleyb> ykarel: glad you could see the agent and confirm master is ok, please add any comments to bug, i already asked about logs but have not seen a reply 13:31:53 <haleyb> next one 13:32:10 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2112620 13:32:11 <haleyb> [neutron-tempest-plugin] Test ``test_vlan_transparent_allowed_address_pairs`` failing 13:32:33 <ralonsoh> I think there is a patch 13:32:40 <ralonsoh> https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/952177 13:32:44 <ykarel> yes this was failing for a known issue in OVN version included in ubuntu jammy 13:32:57 <ykarel> so failing tests skipped in the job for now 13:33:02 <haleyb> ah, the same issue we had seen before 13:33:17 <haleyb> i thought we has over-ridden the image in another patch? 13:33:50 <ykarel> the image change was for guest images, this is related to cloud where ovn runs 13:34:13 <mnaser> https://bugs.launchpad.net/neutron/+bug/2084536 13:34:42 <haleyb> ah yes, thanks for the reminder 13:34:45 <mnaser> This bug seems to have mentioned that the ha chassis group patch would be the ultimate fix however it seems that the patch is abandoned 13:35:03 <ralonsoh> no, this is in progress 13:35:21 <ralonsoh> but there is a previous implementation that needs to land 13:35:34 <haleyb> is this related to the n-t-p bug ? 13:35:35 <ralonsoh> this is the LRP migration to HA_Chassis_Group 13:35:38 <mnaser> I see... so for now technically if we dont patch things that is technically not working for now 13:36:31 <ralonsoh> the point here is how to set the same GW chassis for a external port and the GW LRP 13:36:57 <ralonsoh> for this, we need first to migrate the HA for LRP from gateway_chassis to ha_chassis_group 13:37:45 <mnaser> I see.. any suggestions on stop gap measure since that means ovn + bm + vlan tenant networks is no good 13:38:39 <opendevreview> Elvira García Ruiz proposed openstack/neutron master: Consider logging options when using OVNdbsync https://review.opendev.org/c/openstack/neutron/+/948783 13:38:46 <ralonsoh> a workaround could be to be able to change the external port HA_Chassis_Group to match the LRP gateway_chassis 13:38:57 <ralonsoh> that will land the BM port on the same LRP GW chassis 13:40:57 <haleyb> ok, i'd like to loop back to original bug we were discussing 13:41:00 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2112620 13:41:20 <mnaser> Oh sorry. Meeting. My bad. Ill stay quiet. 13:41:37 <haleyb> ykarel: i noticed that was related-bug - is the only fix updating jammy? 13:42:34 <haleyb> just didn't want the bug open forever if there was nothing else we can really do 13:43:02 <ykarel> yes nothing for us, and doubt if ovn version going to be udpated in jammy 13:43:50 <haleyb> probably not in the base image, no 13:44:40 <haleyb> could we technically create a noble job for this? that should work with 2025.1 i think 13:44:55 <haleyb> although it is already shipping code 13:45:11 <ykarel> we already have noble job in 2025.1 13:45:26 <ykarel> this is the only jammy job we run for 2 distros that supported in release 13:46:01 <haleyb> ah it was right above it :) 13:46:13 <haleyb> ok, thanks for the info 13:46:48 <haleyb> i did not see any other bugs, but if someone has one to discuss you can do so now 13:46:51 <ykarel> Expectation is to have at least one tempest job testing the Ubuntu 22.04 so that the SLURP release upgrade (from 2024.1 to 2025.1) works fine. 13:46:56 <ykarel> from https://governance.openstack.org/tc/reference/runtimes/2025.1.html 13:47:55 <haleyb> right, and it covers python 3.10 13:48:40 <haleyb> ok, if no other bugs we can move on 13:48:59 <opendevreview> Merged openstack/ovn-octavia-provider master: Update default envlist https://review.opendev.org/c/openstack/ovn-octavia-provider/+/939028 13:49:15 <haleyb> oh, rubasov is the deputy this week, next week is mlavalle - is that ok for both? 13:49:22 <mlavalle> yes it is 13:49:41 <haleyb> perfect, i remember bence said it was ok with him last meeting 13:49:48 <mlavalle> he did 13:50:03 <haleyb> #topic community goals 13:50:20 <haleyb> lajoskatona: i did see some neutronclient patches, just haven't been able to keep up 13:51:02 <lajoskatona> yes, reviews coming for the horizon patch also 13:51:33 <lajoskatona> so slow progrss with security-groups, and I hope I can push the Qos one also (https://review.opendev.org/c/openstack/horizon/+/949764) 13:52:25 <lajoskatona> that's it for the SDK topic 13:52:44 <haleyb> lajoskatona: ok, thanks for the update 13:52:57 <haleyb> ralonsoh: and finally eventlet 13:53:09 <ralonsoh> thanks. There are 3 topics 13:53:18 <ralonsoh> OVS agent: https://review.opendev.org/q/topic:%22bug/2087939%22+status:open 13:53:40 <ralonsoh> The last patches are still failing. I'll check tomorrow what is happening there to speed up these patches 13:53:47 <ralonsoh> DHCP agent: https://review.opendev.org/q/topic:%22bug/2087944%22 13:53:58 <ralonsoh> Still waiting for the last patch that removes eventlet from DHCP 13:54:22 <ralonsoh> And "other patches" (mostly related to API and other CLI tools) 13:54:27 <ralonsoh> #link https://review.opendev.org/c/openstack/neutron/+/938404 13:54:27 <ralonsoh> #link https://review.opendev.org/c/openstack/neutron/+/952119 13:54:27 <ralonsoh> #link https://review.opendev.org/c/openstack/neutron/+/952140 13:54:27 <ralonsoh> #link https://review.opendev.org/c/openstack/neutron/+/952142 13:54:27 <ralonsoh> #link https://review.opendev.org/c/openstack/neutron/+/952220 13:54:28 <ralonsoh> #link https://review.opendev.org/c/openstack/neutron/+/950854 13:54:30 <ralonsoh> #link https://review.opendev.org/c/openstack/neutron/+/952117 13:54:33 <ralonsoh> that's all 13:55:19 <ralonsoh> ah, there is a bug in oslo.services 13:55:24 <haleyb> ack, think most (all?) of those last ones are on this topic 13:55:26 <ralonsoh> patch: https://review.opendev.org/c/openstack/oslo.service/+/951505 13:55:27 <haleyb> https://review.opendev.org/q/topic:%2522eventlet-removal%2522+project:openstack/neutron+status:open 13:55:43 <ralonsoh> haleyb, no, not all Neutron patches are under this topic 13:56:14 <ralonsoh> for example, DHCP and OVS are under their own bugs 13:56:25 <haleyb> you're right, some are and some are not, sigh 13:56:37 <frickler> you could use hashtags now 13:56:46 <frickler> allows multiple tags 13:57:35 <ralonsoh> but it was recommended to use the same topic: eventlet-removal 13:57:45 <ralonsoh> I'll change the topic of these patches 13:58:16 <lajoskatona> shall we change the topic for all then? 13:58:24 <ralonsoh> yes please 13:58:28 <lajoskatona> and use dhcp bug specific hashtag for example? 13:58:39 <lajoskatona> ack, I will check my patches 13:59:26 <haleyb> ralonsoh: and regarding the oslo.service patch, i'm guessing there is a neutron patch removing wait_interval? or will be down the line 13:59:43 <ralonsoh> no, the other change 13:59:52 <ralonsoh> calling launch_service multiple times 14:00:06 <ralonsoh> I raised yesterday this issue because of this patch (one sec) 14:00:09 <haleyb> ah ack 14:00:12 <ralonsoh> https://review.opendev.org/c/openstack/neutron/+/952117 14:00:25 <ralonsoh> we spawn several workers in the same process 14:00:32 <ralonsoh> I tested it today and is working, so cool 14:00:45 <cardoe> I was hoping I could ask about https://bugs.launchpad.net/neutron/+bug/2105855 which is my RFE bug for the evpn-vxlan ML2 type. I pushed a first draft of my proposed spec. I was just wondering if I should bring this up during a drivers meeting or post on the ML? 14:00:47 <haleyb> great, thanks 14:01:00 * haleyb has not thought about neutron since last thursday so is out of it 14:01:39 <frickler> just a quick note, missed to mention this for announcements: CLA is getting replaced with DCO https://governance.openstack.org/tc/resolutions/20250520-replace-the-cla-with-dco-for-all-contributions.html 14:01:51 <frickler> starting date will be 2025-07-01, but it doesn't hurt to start signing off your commits earlier. the TC is still working on updating the global contributor docs accordingly 14:01:56 <haleyb> cardoe: one second, let me change topics 14:01:59 <haleyb> #topic on-demand 14:02:24 <haleyb> frickler: yes, thanks for the reminder, will put that in the announcments for next week 14:02:26 <cardoe> apologies I just didn't want the meeting to end 14:02:50 <haleyb> using -s with git commit (or tweaking .gitconfig) should get this behavior 14:03:27 <haleyb> cardoe: ok, go ahead, i do realize we are a little over time 14:04:11 <cardoe> So I've got https://bugs.launchpad.net/neutron/+bug/2105855 and proposed https://review.opendev.org/c/openstack/neutron-specs/+/952166 for it as a first draft. Just wanted to know what the proper next steps are for me to propose this. 14:04:59 <ralonsoh> I'll add this review to my pile for this week 14:05:11 <haleyb> cardoe: i can put it on the agenda, i don't remember discussing at ptg, but could be mistaken 14:05:58 <cardoe> I did discuss it at the PTG. Doug Goldstein was my video name. 14:06:14 <mlavalle> yeap 14:06:27 <haleyb> cardoe: ack, i'll look through the etherpad, too much to remember :) 14:06:45 <mlavalle> so it's a matter of reviewing the spec, right? 14:06:46 <haleyb> i never updated the tags on it correctly 14:07:04 <mlavalle> and getting it merged 14:07:31 <mlavalle> I'll review it this week 14:07:48 <haleyb> thanks, and thanks for the reminder 14:07:57 <haleyb> anything else to discuss? 14:08:05 <ralonsoh> yes 14:08:17 <haleyb> sure 14:08:26 <ralonsoh> (I dont find the link) 14:08:32 <ralonsoh> https://bugs.launchpad.net/neutron/+bug/2112313 14:08:46 <ralonsoh> Once implemented OVN agent with the metadta extension 14:09:00 <ralonsoh> and being that tested in the CI for the last 3 releases (as the default one) 14:09:23 <ralonsoh> I think we should start during this release to send deprecation messages 14:09:26 <ralonsoh> and the remove the code 14:09:42 <ralonsoh> So, just to know what the schedule should be 14:09:57 <ralonsoh> for how long should we just write a deprecation warning? 14:10:49 <cardoe> I wanted to ask about mapping a port to the network segment. Ironic does https://opendev.org/openstack/ironic/src/branch/master/ironic/common/neutron.py#L1053 which walks the IP addresses for matching. Which works fine with routed networks. But if you're using l2_adjacency, is there anything that stores what segment the port is bound to? 14:11:07 <ralonsoh> if we start now, that should include 2026.1 (SLURP) and I think we could remove everything in 2026.2 (before 2027.1) 14:11:09 <ralonsoh> right? 14:11:26 <haleyb> ralonsoh: i would agree we can move to deprecate, don't know how many releases, but 2026.2 seems sane 14:11:59 <ralonsoh> ok, I'll send a patch now and check what other CI jobs are still using OVN metadata and migrate to OVN agent 14:12:00 <haleyb> i will make sure it's known to our team here that does the config work 14:12:16 <ralonsoh> the CI has examples of that 14:12:24 <ralonsoh> it is used in the neutron jobs 14:12:32 <haleyb> ralonsoh: is there even much for migration? just adding the option that starting the new agent, stopping the existing? 14:12:52 <haleyb> s/then starting the new agent, can't type 14:13:10 <ralonsoh> https://zuul.opendev.org/t/openstack/builds?job_name=neutron-tempest-plugin-ovn&skip=0 14:13:53 <ralonsoh> not really, you can stop one and start the other 14:13:58 <ralonsoh> nothing else 14:14:15 <haleyb> ralonsoh: right, should not be complicated, perfect 14:14:42 <haleyb> alright, we are :15 over so i'll end the meeting 14:14:57 <haleyb> thanks for attending everyone, and feel free to continue discussions 14:15:07 <haleyb> #endmeeting