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