13:00:04 <mlavalle> #startmeeting networking 13:00:04 <opendevmeet> Meeting started Tue Jul 22 13:00:04 2025 UTC and is due to finish in 60 minutes. The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:04 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:04 <opendevmeet> The meeting name has been set to 'networking' 13:00:25 <mlavalle> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, haleyb, ralonsoh 13:00:32 <slaweq> o/ 13:00:34 <lajoskatona> o/ 13:00:36 <bcafarel> o/ 13:00:44 <elvira> o/ hi 13:00:49 <ykarel> o/ 13:01:35 <mtomaska> o/ 13:01:37 <ralonsoh> hello 13:01:49 <mlavalle> #announcements 13:02:11 <rubasov> o/ 13:02:26 <cbuggy> o/ 13:02:33 <mlavalle> Hi everybody. As you might remember, our fearless leader is on PTO this week 13:03:01 <mlavalle> We are currently in Week R-10 of Flamingo 13:03:39 <mlavalle> Our next milestone in this development cycle will be Flamingo-3, week of August 25th 13:04:20 <mlavalle> Final 2025.2 Flamingo release: October 3rd, 2025 13:05:06 <mlavalle> #link https://releases.openstack.org/flamingo/schedule.html 13:05:53 <mlavalle> The next OpenInfra PTG will take place October 27-31, 2025 and registration for the event is now open 13:06:13 <mlavalle> #link https://ptg.openinfra.dev/ 13:07:37 <mlavalle> Reminder: this Friday the drivers meeting is cancelled but if you have topics for next week, please add it to the wiki @ https://wiki.openstack.org/wiki/Meetings/NeutronDrivers 13:08:30 <mlavalle> that was all the announcements i had, any others? 13:09:34 <mlavalle> ok, moving on 13:09:38 <mlavalle> #topic bugs 13:10:22 <mlavalle> Last week's deputy was sahid, but I didn't find his report. Did anybody see it? 13:10:44 <lajoskatona> nope 13:11:10 <ralonsoh> hmmm my bad, I should have checked it on monday 13:11:51 <mlavalle> that's ok. let's spend a few minutes triaging some bugs here 13:11:59 <ralonsoh> anyway, we have several new ones 13:12:02 <ralonsoh> that are not assigned 13:12:16 <ralonsoh> OVN: Intermittent metadata failures for SR-IOV VMs 13:12:21 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2117078 13:12:56 <ralonsoh> I tried to quick triage this bug 13:13:03 <mlavalle> I see that 13:13:07 <ralonsoh> but to debug this issue we would need some logs 13:13:27 <ralonsoh> in particular when the port is bound and when it tries to retrieve the metadata 13:13:36 <ralonsoh> I'll ask for all of them, if possible 13:14:01 <mlavalle> ok, you follow up that one 13:14:05 <mlavalle> thanks 13:14:26 <ralonsoh> next one 13:14:32 <ralonsoh> neutron-openvswitch-agent crashes on start 13:14:36 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2117153 13:14:47 <ralonsoh> This folk is using an old version 13:15:03 <ralonsoh> and it stating that cannot reproduce it with a newer version 13:15:07 <ralonsoh> (if I'm not wrong) 13:15:26 <mlavalle> yeap 13:15:40 <mlavalle> that's what he says 13:15:50 <ralonsoh> so I would just suggest to update os-ken and test again 13:15:55 <ralonsoh> I'll update the LP bug 13:16:03 <mlavalle> sounds good 13:16:16 <ralonsoh> (but to be honest, I didn't find any revelant patch in os-ken) 13:16:40 <ralonsoh> next one 13:16:41 <ralonsoh> [eventlet-removal] Add H999 hacking check to ban eventlet imports 13:16:46 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2117373 13:16:50 <ralonsoh> I'll assign this one to me 13:16:54 <mlavalle> that is under control by you 13:16:54 <ralonsoh> but this is for everyone 13:16:58 <ralonsoh> I mean 13:17:09 <ralonsoh> for any networking project that removes eventlet 13:17:15 <ralonsoh> it is needed to do something like this: 13:17:19 <ralonsoh> https://review.opendev.org/c/openstack/networking-sfc/+/955295 13:17:27 <mlavalle> I see what you mean 13:17:32 <mlavalle> undestood 13:17:48 <ralonsoh> next one 13:17:48 <ralonsoh> [neutron-tempest-plugin] Test ``test_create_router_update_external_gateways`` failing 13:17:48 <lajoskatona> I ill check stadiums this week I hope for this one 13:17:55 <ralonsoh> lajoskatona, thanks! 13:18:04 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2117383 13:18:11 <ralonsoh> I opened this one because I saw this error 13:18:15 <ralonsoh> but only once 13:18:38 <ralonsoh> but that could be a problem in the testing FW 13:18:45 <ralonsoh> Details: {'type': 'IpAddressAlreadyAllocated', 'message': 'IP address 172.24.5.33 already allocated in subnet 8936b536-5feb-4f28-ae4d-6733056bf18c', 'detail': ''} 13:19:05 <ralonsoh> but, to be honest, I did see this problem once 13:19:24 <ralonsoh> next one 13:19:25 <ralonsoh> test_subport_delete random failure 13:19:31 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2117405 13:19:41 <ralonsoh> I told ykarel to assign this one to me 13:19:42 <mlavalle> I can follow the one for the tempest test 13:19:48 <ralonsoh> mlavalle, thanks! 13:20:03 <ralonsoh> so I assigned 2117405 to me 13:20:14 <ykarel> thx ralonsoh i forgot to assign that 13:20:22 <ralonsoh> no problem at all 13:20:33 <ralonsoh> next one 13:20:34 <ralonsoh> Horizon shows all prefix lengths when creating subnet from subnet pool 13:20:39 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2116927 13:21:33 <ralonsoh> to be honest, I don't know if that is a problem in horizon or neutron 13:21:54 <ralonsoh> Neutron is failing as expected 13:22:14 <lajoskatona> I think it is irealted to my work in Horizon so I am on it 13:22:38 <lajoskatona> I commented, but will assign it to myself 13:22:40 <ralonsoh> so maybe, after this patch, horizon is not enforcing the subnet mask 13:22:50 <mlavalle> thanks lajoskatona 13:22:51 <ralonsoh> subnet range 13:22:57 <ralonsoh> lajoskatona, thanks for taking care 13:23:30 <ralonsoh> last one is already assigned, Bence sent some patches to um branches: https://bugs.launchpad.net/neutron/+bug/2117477 13:23:33 <ralonsoh> and that's all 13:23:37 <mlavalle> and the last LP in the list is already owned by rubas 13:23:43 <mlavalle> rubasov: 13:23:53 <mlavalle> we are caught up 13:24:38 <mlavalle> any other bugs to discuss? 13:25:09 <yusufgungor_> yes @mlavalle we have 13:25:23 <yusufgungor_> can i talk about it? 13:25:59 <mlavalle> it would be better if you open a report in Launchpad 13:26:45 <mlavalle> that way the conversation is recorded in the report and everybody can follow it 13:26:56 <yusufgungor_> yes there exist a launchpad report, actually we want to talk about the review of that bug 13:27:38 <mlavalle> what's the report and the associated patch? 13:27:45 <mlavalle> go ahead 13:28:13 <yusufgungor_> a bug fix for neutron bgp dynamic routing : https://bugs.launchpad.net/neutron/+bug/2100752 13:28:13 <yusufgungor_> Lajos Katona (@lajoskatona) and Jens Harbott (@frickler) reviewed it already. 13:28:13 <yusufgungor_> 13:28:13 <yusufgungor_> @frickler deferred to other reviewers after his review. 13:28:14 <yusufgungor_> We think it is a critical bug and should be fixed and want some guidance to progress it. 13:28:16 <yusufgungor_> https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/953428 13:29:39 <ralonsoh> The main problem with this patch is that almost nobody can test it and that we don't know the code well to review it 13:29:51 <lajoskatona> I asked some test coverage for the issue, is that possible in our current CI? (sorry I have to check the details again as it was weeks ago) 13:31:51 <yusufgungor_> @lajoskatona we also discussed the test coverage issue with @frickler, but it will be over engineering. it is really simple fix which only add one more filter while getting the port from db 13:33:00 <yusufgungor_> local test scenarios also written under review discussion 13:34:06 <lajoskatona> yes from that perspective you are right that the patch itself is quite simple filtering for the case when the port is migrated 13:36:36 <mlavalle> so if we find a way to test the fix in our CI, could we move ahead with this review? 13:37:22 <mlavalle> the size of the fix doesn't preclude the need for testing it 13:37:38 <yusufgungor_> when getting the ports from DB, now are adding a new filter "ML2PortBinding.status == lib_consts.ACTIVE" 13:37:38 <yusufgungor_> I think the main question is should bgp advertise a port ip with not ACTIVE status? I think we should not. 13:38:55 <yusufgungor_> @mlavalle you are right, but in this patch we are not adding a new feature or complex fix. Existing test coverage could find the problem if any exist on this patch 13:40:43 <mlavalle> under that assumption, code coverage would diminish over time constantly 13:41:19 <lajoskatona> +1 13:41:31 <mlavalle> here's the situation: 13:42:08 <lajoskatona> Perhaps we can just make sure that the above assertion (port.status==ACTIVE to be advertised the IP) add to existing tests in neutron-tempest-plugin 13:42:26 <mlavalle> on one hand we don't have in the community all the expertise to review this code with confidence 13:43:16 <yusufgungor_> @mlavalle so we can say every bug fix has a responsibility to increase the test coverage even minor ones 13:43:46 <yusufgungor_> so can we say neutron dynamic routing deprecated? 13:43:51 <mlavalle> on the other, if we can make everybody confident that we are not introducing side effects with some sort of testing, we could move forward 13:44:43 <mlavalle> yusufgungor_: we are a community and we try as much as we can to help each other. help us to help you 13:45:50 <yusufgungor_> @mlavalle i know, thanks for your great efforts. Do you know any other guys who are using neutron bgp dynamic routing? we may let them to test locally? 13:46:44 <mlavalle> I'll initiate a thread in the mailing list about this issue. Let's see if somebody offers help 13:47:17 <lajoskatona> ack, thanks 13:47:34 <yusufgungor_> @mlavalle thanks. we also can write a test, but since we will be the ones writing the test, it won't be very meaningful when it comes to testing the test. 13:48:07 <mlavalle> let us see your test proposal anyways 13:48:42 <mlavalle> for now, let's move on 13:48:47 <lajoskatona> +1, tests can help to better understand the situation, so I hope it will help 13:49:34 <yusufgungor_> as we discussed with @frickler under review, the test will be much more complex than this small fix. Since there isn't enough developer to understand this fix, it won't be possible to decide whether the test is sufficient and correct. 13:50:05 <mlavalle> this week's deputy is jlibosva. he is not online but I will make sure he is aware 13:50:45 <mlavalle> #topic community goals 13:51:08 <mlavalle> any updates from neutronclient, lajoskatona 13:51:10 <mlavalle> ? 13:51:45 <lajoskatona> no, just the bug from Horizon we discussed earlier 13:52:06 <mlavalle> thanks 13:52:17 <mlavalle> how about eventlet, ralonsoh ? 13:52:20 <ralonsoh> yes 13:52:25 <ralonsoh> I'm fighting with https://review.opendev.org/c/openstack/neutron/+/952258 13:52:35 <ralonsoh> I've managed to execute all UTs withoyt eventlet 13:52:45 <ralonsoh> there are some UTs skipped... 13:52:50 <ralonsoh> we can manage this later 13:52:57 <ralonsoh> but the main problem is zuul/CI 13:53:12 <ralonsoh> I cannot pass the needed variables to FT CI to run it with eventlet 13:53:18 <ralonsoh> https://zuul.opendev.org/t/openstack/status?change=952258 13:53:40 <ralonsoh> I'll push a new PS to limit the execution of FT to a couple of tests 13:53:47 <ralonsoh> and I'll ask qa folks about this 13:54:01 <ralonsoh> I'm must be doing something wrong in tox 13:54:05 <ralonsoh> that's all I have 13:54:35 <mlavalle> thanks for the update and hard work on this topic 13:55:02 <mlavalle> #topic on-demand 13:55:15 <mlavalle> any other topics we should discuss today? 13:55:33 <cardoe> There's a patch that Ironic would really like to see landed that I wanted to mention. 13:55:50 <mlavalle> cardoe: ok, which one? 13:56:00 <cardoe> https://review.opendev.org/c/openstack/neutron/+/945497 13:56:36 <mlavalle> it's in my pile. I'll review it today 13:56:41 <ralonsoh> ah ok, let me check again it 13:58:35 <mlavalle> anything else? 13:59:23 <mlavalle> ok, have a great week 13:59:27 <mlavalle> #endmeeting