14:00:30 <haleyb> #startmeeting networking 14:00:30 <opendevmeet> Meeting started Tue Feb 4 14:00:30 2025 UTC and is due to finish in 60 minutes. The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:30 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:30 <opendevmeet> The meeting name has been set to 'networking' 14:00:40 <haleyb> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, haleyb, ralonsoh 14:00:41 <mlavalle> \o 14:00:46 <elvira> o/ 14:00:48 <mtomaska> o/ 14:00:50 <slaweq> o/ 14:00:53 <frickler> \o 14:01:09 <ralonsoh> hello 14:01:16 <cbuggy> o/ 14:01:32 <lajoskatona> o/ 14:01:46 <haleyb> #announcements 14:01:48 <rubasov> o/ 14:01:57 <haleyb> We are in week R-8 of Epoxy 14:01:59 <mblue_> o/ 14:02:06 <haleyb> E-3 milestone at week R-5 (Feb 24) 14:02:07 <sahid> o/ 14:02:17 <bcafarel> o/ 14:02:20 <haleyb> #link https://releases.openstack.org/epoxy/schedule.html 14:02:32 <haleyb> So about 3 weeks until feature freeze 14:03:23 <haleyb> Any code changes for RFEs should be posted very soon 14:03:40 <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 14:04:05 <haleyb> I will triage by thursday and send email about meeting 14:04:36 <haleyb> And of course a reminder to use the priorities dashboard for patches in the "ready to merge" state 14:04:51 <haleyb> Those should be focus of reviews 14:05:36 <haleyb> We merged the Linuxbridge driver removal last week )-; 14:05:39 <haleyb> or :) 14:05:43 <bcafarel> \o/ 14:06:05 <lajoskatona> yesterday we discussed the side effects of it as bagpipe is broken since that 14:06:11 <slaweq> one thing to mention regarding linux bridge removal 14:06:27 <slaweq> during the FOSDEM there was OpenStack BoF session 14:06:38 <slaweq> there was pretty many operators there 14:06:39 <lajoskatona> I checked this morning and part of bagpipe is fully lb dependent (I was in the beleief that everything is working in it on OVS and lb) 14:06:55 <slaweq> and I asked about LB if anyone is really using it and that we removed it 14:07:27 <slaweq> and good news is that nobody from those people was actually shocked with this, and nobody told us that is still using LB :) 14:07:46 <lajoskatona> good news really :-) 14:07:47 <slaweq> so this is kind of confirmation that we did right thing with it IMHO 14:07:52 <haleyb> phew, i thought you were going to say they got their pitchforks 14:08:06 <ralonsoh> so what should we do with bagpipe? 14:08:26 <slaweq> haha, then I would not be here today probably :P 14:08:44 <haleyb> lajoskatona: has there been work on moving to OVS, etc? 14:08:57 <lajoskatona> ralonsoh: as I checked this morning the part realted to SFC is mostly linuxbridge 14:09:29 <lajoskatona> haleyb: I don't know about it, at least not in the last ~4 years let's say 14:10:21 <haleyb> and sorry i was out yesterday and didn't see your message in scrollback until just now 14:10:49 <lajoskatona> haleyb: no problem, today with the meeting is perhaps better anyway 14:11:16 <ralonsoh> we can make this public, sending a mail with a warning 14:11:28 <lajoskatona> +1 14:11:28 <ralonsoh> and asking developers to support OVN in bagpipe 14:11:45 <ralonsoh> if not, we'll need to retire it along with LB 14:13:20 <ralonsoh> last release note with a new feature is from rocky 14:13:20 <ralonsoh> https://docs.openstack.org/releasenotes/networking-bagpipe/rocky.html 14:13:30 <ralonsoh> and it says that evpn is supported in OVS too 14:13:41 <lajoskatona> ralonsoh: agree, if there's users for it than its time to raise their hands (we, Ericsson seems to stopped using it in the last years) 14:13:53 <haleyb> i was just checking the repo and there hasn't been a lot of development, mostly fixing bugs as we've moved forward with python 14:14:39 <ralonsoh> maybe (maybe) we can remove just the sfc part 14:14:40 <lajoskatona> that was my guess also 14:15:12 <lajoskatona> ralonsoh: I can check it if it is a simple operation to safely cut and add documentation, and reduce the test coverage for it 14:15:30 <ralonsoh> cool, let's do this first 14:15:40 <lajoskatona> let's wait this week than, I check it in a time boxed manner, and let's check this topic next week 14:16:07 <haleyb> lajoskatona: ack, can you file a bug with this info so we don't forget? 14:16:14 <lajoskatona> sure 14:17:54 <haleyb> the other email i sent last week to ML was regarding removal of dibbler PD driver. I don't see any responses so we can merge that this week as well 14:18:23 <haleyb> #link https://review.opendev.org/c/openstack/neutron/+/934283 14:20:09 <haleyb> the other thing i did last week was remove the inclusion of networking-ovn-core into neutron-core - i sent email to list "promoting" Terry into the neutron-core group 14:21:17 <haleyb> last announcement is it's PTL/TC election season for 2025.2 cycle 14:21:25 <haleyb> nomination period starts tomorrow 14:22:00 <slaweq> that is correct, please expect kick off email tomorrow night 14:22:53 <haleyb> and if anyone is interested in PTL please ping me, I am more than happy to talk about it 14:23:04 <haleyb> but i would gladly server another term/cycle 14:23:27 <lajoskatona> thanks haleyb 14:24:08 <haleyb> i have no other announcements, anyone else? 14:24:12 <mlavalle> haleyb: yaay! thanks 14:24:52 <haleyb> #topic bugs 14:25:09 <haleyb> mtomaska was bug deputy last week 14:25:12 <haleyb> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/P5KLBE5NEY7LEJASIWMOVFIK4LDLXYC2/ 14:25:36 <mtomaska> yep o/ 14:26:05 <haleyb> critical one has a patch in the gate queue 14:26:08 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2096912 14:26:13 <haleyb> so all good there 14:26:44 <ralonsoh> and another 3 dependant patches 14:26:56 <haleyb> oh 14:27:10 <ralonsoh> https://review.opendev.org/q/topic:%22bug/2096912%22 14:28:29 <haleyb> perfect, thanks for fixing that slaweq and to reviewers 14:29:01 <haleyb> next was marked high 14:29:05 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2096941 14:29:11 <haleyb> [OVN Routed Provider Networks] : New Compute nodes are not added to their segment aggregate 14:29:27 <haleyb> otherwiseguy picked that up 14:29:52 <slaweq> yw :) 14:29:59 <haleyb> #link https://review.opendev.org/c/openstack/neutron/+/935990 14:30:06 <slaweq> I needed it to make my QinQ patches to be merged :) 14:30:54 <haleyb> slaweq: yes, i saw those were in the queue related to the change 14:31:07 <haleyb> next bug is 14:31:13 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2096983 14:31:20 <haleyb> [OVN] Error executing command (LspGetUpCommand): ovsdbapp.backend.ovs_idl.idlutils.RowNotFound 14:31:28 <haleyb> ralonsoh: you filed this 14:31:36 <ralonsoh> it seems that is not affecting the API 14:31:44 <ralonsoh> but it is horrible to see that in the logs 14:32:01 <mtomaska> This one is pretty high IMO. I was on PTO last week so I did not have much time to sit down and track it. 14:32:02 <ralonsoh> if this is a expected behaviour, we should format the logs differently 14:32:12 <ralonsoh> I wouldn't say high 14:32:15 <mtomaska> Agree, very "bad" log to see 14:32:34 <ralonsoh> that happens when we try to bind a port but this is no longer present 14:32:44 <ralonsoh> and we try to find it in the OVN DB 14:33:06 <mtomaska> I feel like it might cause lot of customer support tickets.... 14:34:22 <mtomaska> if we know why it is happening then why not just catch it and not log it? 14:34:46 <haleyb> right, should this be in try/except if it's ok? 14:35:15 <ralonsoh> better ovn lookup with default value 14:35:25 <ralonsoh> but this is for the developer taking this bug 14:35:52 <ralonsoh> mtomaska, it is needed first to properly investigate the cause 14:35:56 <otherwiseguy> Yeah, I'm trying to investigate this a bit too in concert with my patch for resolving some race conditions between inserts and updates/deletes that happen on different workers. 14:36:06 <mtomaska> but from the bug I was not sure if we know for a fact that this is safe to catch. It seems like we need better RCA before making that conclusion. No? 14:36:27 <ralonsoh> of course, that requires a previous investigation 14:36:36 <ralonsoh> my report only presents the consequences, not the causes 14:36:49 <mtomaska> ACK 14:37:43 <haleyb> ok, otherwiseguy did you want to take that one as well? 14:37:43 <mtomaska> I can look into it. I just dont know how much time I am committing :) 14:38:07 <otherwiseguy> haleyb: mtomaska: I can take it since I'm looking at it regardless :) 14:38:18 <ralonsoh> thanks folks 14:38:47 <haleyb> ok, thanks terry 14:39:23 <mtomaska> otherwiseguy++ 14:40:12 <haleyb> next one is ovn-related 14:40:17 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2096931 14:40:24 <haleyb> Duplicate packets with router betwen flat network and vlan network 14:42:06 <ralonsoh> hold on, now I realize 14:42:06 <mtomaska> O yeah that one. My first instinct is that , "yeah maybe OVN does that under some circumstances" but then I did not really fully understand his network. I see he posted his ovn nb db output 14:42:18 <ralonsoh> that could be also related to https://review.opendev.org/c/openstack/neutron/+/940454 14:42:28 <ralonsoh> we found that when "playing" with flat networks 14:42:40 <ralonsoh> that was something solved in 2024.2 but not backported 14:43:06 <ralonsoh> I'll ask this folk to test with these new patches 14:43:49 <haleyb> ralonsoh: thanks, i would not have made that connection 14:44:37 <haleyb> and last bug 14:44:39 <ralonsoh> (and now you are here, please review https://review.opendev.org/q/topic:%22bug/2073987%22) 14:44:42 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2097212 14:44:50 <haleyb> Resolv.conf search domain is different from the network's dns_domain 14:45:04 <haleyb> ralonsoh: ack, will do 14:45:40 <mtomaska> I asked mlavalle to take a quick look. As it requires dns extension. 14:46:02 <mlavalle> I haven't had time to llok at it. But I'll do it later today 14:46:22 <haleyb> mlavalle: thanks! 14:46:35 <mlavalle> :-) 14:46:35 <haleyb> alright, any other bugs to dicsuss? 14:46:42 <ralonsoh> yes 14:46:46 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2093258 14:46:50 <ralonsoh> reopened today 14:47:03 <ralonsoh> c#3 has the request and c#4 has the context 14:47:15 <ralonsoh> and the patch: https://review.opendev.org/c/openstack/neutron-lib/+/940682 14:47:48 <ralonsoh> (also in the IRC history today) 14:48:33 <ralonsoh> that's all from me 14:49:11 <haleyb> thanks for looking into it, will review after meeting 14:49:49 <haleyb> #topic community goals 14:50:05 <haleyb> lajoskatona: i'll let you go first with any neutronclient update 14:50:27 <lajoskatona> some progress in reviews for Horizon patches 14:50:45 <lajoskatona> https://review.opendev.org/q/topic:%22bug/1999774%22+status:open 14:51:25 <haleyb> thanks, i see a new one was added will take a look later 14:52:16 <haleyb> and last is eventlet 14:52:20 <lajoskatona> that is cleaning in test files for old data containers 14:52:32 <ralonsoh> about eventlet, there are two fronts 14:52:40 <ralonsoh> OVS agent: sahid's patches 14:52:47 <ralonsoh> sahid, something to comment? 14:53:50 <ralonsoh> and the Neutron API, in particular now the OVN hash ring. I've pushed https://review.opendev.org/c/openstack/neutron/+/940256 and the upper 2 patches 14:53:55 <lajoskatona> https://review.opendev.org/q/topic:%22bug/2087939%22+owner:sahid.ferdjaoui@industrialdiscipline.com 14:54:20 <opendevreview> Merged openstack/ovn-octavia-provider master: Remove join on helper request daemon thread https://review.opendev.org/c/openstack/ovn-octavia-provider/+/938797 14:54:22 <ralonsoh> otherwiseguy, made some comments but I would like to remark that the periodic maintenance task no longer works if the API is idle 14:54:39 <sahid> ralonsoh: sorry nothing at that point, continuing my progresses 14:54:41 <ralonsoh> this is why I'm changing how the hash ring nodes are refreshed 14:54:46 <ralonsoh> sahid, thanks! 14:54:58 <otherwiseguy> ralonsoh: but will work if you change the executor from SynchronousExecutor 14:55:11 <ralonsoh> I did that before and didn't work 14:55:18 <ralonsoh> I proposed a testing patch 14:55:30 <otherwiseguy> (not specifically for the reworked hashring, but I tested it and it worked) 14:55:39 <ralonsoh> I'll find this patch after the meeting 14:56:02 <otherwiseguy> hasring touches went from like 5 to one every 15 seconds or whatever. 14:56:32 <ralonsoh> yes, executed by worker 1 in each node 14:58:14 <ralonsoh> (that's all from me) 14:58:51 <haleyb> ack, thanks for the update 14:58:59 <haleyb> #topic on-demand 14:59:03 <haleyb> any other topics? 14:59:12 <haleyb> i have a hard stop in :1 14:59:17 <lajoskatona> I have one small thing, please review these: 14:59:19 <lajoskatona> https://review.opendev.org/q/owner:katonalala@gmail.com+label:Review-Priority%3D2+status:open 14:59:45 <lajoskatona> and Liu also has some patches as review prioriy+2, I tested the metadata things from him 14:59:54 <lajoskatona> that's it :-) 15:00:15 <haleyb> lajoskatona: yes, i will look at those as well, thanks for the reminder 15:00:31 <haleyb> ok, have a good week everyone and thanks for attending 15:00:38 <haleyb> #endmeeting