14:00:49 <haleyb> #startmeeting networking
14:00:49 <opendevmeet> Meeting started Tue Dec 17 14:00:49 2024 UTC and is due to finish in 60 minutes.  The chair is haleyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:49 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:49 <opendevmeet> The meeting name has been set to 'networking'
14:00:51 <haleyb> Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki, haleyb, ralonsoh
14:00:58 <ralonsoh> hello
14:00:59 <obondarev> hi
14:01:05 <s3rj1k> hi all
14:01:13 <cbuggy> Hello o/
14:02:11 <rubasov> o/
14:02:15 <bcafarel> o/
14:02:25 <haleyb> ok we can get started
14:02:28 <haleyb> #announcements
14:02:35 <haleyb> #link https://releases.openstack.org/epoxy/schedule.html
14:02:42 <haleyb> We are currently in week R-15
14:02:51 <haleyb> Epoxy-2 milestone R-12 (week of Jan 6th)
14:03:17 <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:09 <haleyb> But there is not another scheduled drivers meeting for a while
14:05:12 <haleyb> I hope everyone saw my email on meetings for rest of year (i know ykarel did :)
14:05:36 <haleyb> Next CI meeting is Jan 6th
14:05:54 <haleyb> Next Neutron meeting is Jan 7th (mlavalle chair)
14:06:04 <haleyb> Next Drivers meeting Jan 10th
14:06:56 <haleyb> I did have a note in that meeting about my own availability
14:07:00 <haleyb> I will be offline from December 19th to January 8th, checking-in occasionally to make sure there are no fires
14:07:58 <haleyb> that is my plan ^^ but i probably will check email every other day until Jan 1st
14:08:31 <haleyb> Then you will only find me if you are sitting at the beach next to me sharing a cocktail
14:09:01 <slaweq> hi, sorry for being late
14:09:38 <haleyb> I hope everyone will take some time off to enjoy their family/friends too, Neutron will still be here :)
14:10:00 * haleyb feels like a Dad today
14:10:58 <ihrachys> :D
14:11:02 <haleyb> last announcement i have is my weekly reminder
14:11:03 <haleyb> Let's continue to use the priorities dashboard for patches in the "ready to merge" state (weekly reminder)
14:11:12 <ihrachys> thank you Grandpa for the holiday wisdom
14:12:05 <slaweq> :D
14:12:30 <haleyb> hey! no grandkids yet, don't rush things
14:13:10 <haleyb> and get off my lawn!
14:13:27 <haleyb> again, bad Dad jokes is all i have
14:14:05 <opendevreview> Sahid Orentino Ferdjaoui proposed openstack/neutron master: ml2/ovs: improve log message for ports without VLAN tags/net-id during OVS restore  https://review.opendev.org/c/openstack/neutron/+/929908
14:14:06 <opendevreview> Sahid Orentino Ferdjaoui proposed openstack/neutron master: ml2/ovs: change log level from DEBUG to WARNING for port deletion during binding  https://review.opendev.org/c/openstack/neutron/+/929909
14:14:12 <haleyb> any other announcements?
14:14:25 <opendevreview> Sahid Orentino Ferdjaoui proposed openstack/neutron master: ml2/ovs: change log level from DEBUG to INFO for port deletion during binding  https://review.opendev.org/c/openstack/neutron/+/929909
14:14:54 <haleyb> let's move on
14:15:03 <haleyb> #topic bugs
14:15:13 <haleyb> ihrachys was the deputy last week
14:15:19 <haleyb> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/QNUVMQ4WRKHVAQIAKIRLQZMX5FBMMT42/
14:16:02 <haleyb> there were a couple related to gate issues that have owners and fixes
14:16:56 <haleyb> this revert should help with the l3-ha issues
14:17:00 <haleyb> #link https://review.opendev.org/c/openstack/neutron/+/937758
14:17:10 <opendevreview> Merged openstack/neutron master: Revert "[HA] Do not add initial state change delay in HA router"  https://review.opendev.org/c/openstack/neutron/+/937758
14:17:15 <opendevreview> Merged openstack/neutron-tempest-plugin master: Turn off wsgi in linuxbridge stable branch jobs  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/937842
14:17:22 <haleyb> but as amorin asked there, will that just re-introduce the original bug?
14:17:47 <ralonsoh> the bug this patch was solving was in the FTs only
14:18:08 <ihrachys> "FTs"?
14:18:12 <ralonsoh> functional tests
14:18:20 <ralonsoh> https://bugs.launchpad.net/neutron/+bug/1945512
14:18:27 <ralonsoh> so I think we are ok with this revert
14:18:40 <ralonsoh> if we find again the FTs errors, we can address them in a better way
14:19:15 <amorin> what I saw in our downstream openstack was the following: https://bugs.launchpad.net/neutron/+bug/2083237
14:19:24 <amorin> I was wondering if the revert will fix it?
14:19:42 <ralonsoh> yes it should
14:19:44 <ykarel> amorin, yes the revert should help in the scenario mentioned in the bug
14:19:55 <amorin> perfect, thanks :)
14:20:03 <haleyb> ok, so https://review.opendev.org/c/openstack/neutron/+/929406 shouldn't be required any more
14:20:24 <amorin> I believe so, I can abandone and mark this as related to the revert
14:20:31 <amorin> same on the launchpad bug, agree?
14:20:41 <ralonsoh> yes
14:21:13 <haleyb> great
14:21:50 <haleyb> next bug
14:21:58 <opendevreview> Stanislav Dmitriev proposed openstack/neutron master: HA VRRP health check parameters  https://review.opendev.org/c/openstack/neutron/+/932716
14:21:59 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2091711
14:22:08 <haleyb> SG list failure on stable branches
14:22:13 <ralonsoh> I saw it once only
14:22:27 <ralonsoh> and in postgre CI
14:22:36 <ralonsoh> if we don't see it again, we can close it
14:23:09 <haleyb> ralonsoh: ack
14:24:00 <haleyb> next bug
14:24:06 <haleyb> #link https://bugs.launchpad.net/neutron/+bug/2091211
14:24:13 <haleyb> network leakage for flat network
14:25:44 <haleyb> as ihrachys noted, it looks like a legit bug, and there are some good notes there
14:26:36 <haleyb> i will watch it but do not have time to pick it up
14:26:53 <ihrachys> should mac-aging-time update with "other" traffic as the reporter suggests?
14:27:51 <ralonsoh> I don't know if Saeed is only using the explicitly_egress_direct=True option
14:28:03 <ralonsoh> this is preventing from using the MAC table
14:28:12 <ralonsoh> because the packet is not using the normal action
14:28:16 <ralonsoh> that was a reported issue
14:28:19 <haleyb> ralonsoh: that is set in his notes
14:28:23 <ralonsoh> I know
14:28:35 <ralonsoh> but I don't know if he tested with and without this flag
14:29:31 <ralonsoh> there: https://bugs.launchpad.net/neutron/+bug/1884708 (also in the notes)
14:29:37 <haleyb> ralonsoh: when you say it was a reported issue - with neutron or OVS? ah
14:30:17 <ralonsoh> it is supposed to be fixed but maybe this patch was not considering FLAT networks
14:31:13 <ralonsoh> I'll comment that in the bug today
14:31:46 <haleyb> thanks ralonsoh
14:32:18 <haleyb> that was all for the bugs
14:33:20 <haleyb> i did have one question regarding the l3-ha revert (which just merged), guess that needs backports
14:33:25 <haleyb> #link https://review.opendev.org/c/openstack/neutron/+/937758
14:33:54 <ykarel> yes pushing those
14:33:59 <ykarel> fixing conflicts :)
14:34:02 <haleyb> ykarel: thanks
14:34:26 <haleyb> are there any other gate issues we should focus on?
14:34:50 <ralonsoh> the issues with wsgi migration (and the related fixes)
14:35:09 <ykarel> ++ ^ the other main ones
14:35:10 <ralonsoh> that usually affect loaded envs (with more API workers)
14:35:21 <ralonsoh> still working on why the Neutron API misses the events...
14:36:43 <haleyb> ok, just want to cut-down the number of rechecks if possible
14:37:50 <haleyb> ok, if no other bugs we can move on
14:37:56 <haleyb> #topic community goals
14:38:09 <haleyb> i see there was a little movement on neutronclient deprecation ?
14:38:12 <opendevreview> yatin proposed openstack/neutron stable/2024.2: Revert "[HA] Do not add initial state change delay in HA router"  https://review.opendev.org/c/openstack/neutron/+/937878
14:38:16 <ralonsoh> not really
14:38:16 <haleyb> #link https://review.opendev.org/q/topic:%22bug/1999774%22
14:38:55 <haleyb> well at least one +2 on the routers one
14:39:04 <opendevreview> yatin proposed openstack/neutron stable/2024.1: Revert "[HA] Do not add initial state change delay in HA router"  https://review.opendev.org/c/openstack/neutron/+/937879
14:39:23 <haleyb> i don't see lajos here today to discuss further
14:39:34 <opendevreview> yatin proposed openstack/neutron stable/2023.2: Revert "[HA] Do not add initial state change delay in HA router"  https://review.opendev.org/c/openstack/neutron/+/937880
14:39:50 <haleyb> other community goal is eventlet
14:39:52 <haleyb> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=eventlet-deprecation
14:40:13 <ralonsoh> I have this
14:40:13 <ralonsoh> https://review.opendev.org/c/openstack/neutron/+/937545
14:40:37 <ralonsoh> I have a working metadata server (for OVN metadata agent and OVN agent) that works without eventlet
14:40:48 <ralonsoh> the issue (and I'll send a mail for this)
14:41:17 <ralonsoh> this implementation only adds the threading option, that means the embbeded server that runs in the same process
14:41:32 <ralonsoh> so the option metadata_workers is not not valid
14:42:03 <ralonsoh> I implemented this option only (for now) because it was easier and not dependant on, for example, oslo.services
14:42:33 <ralonsoh> to implement a multiprocess metadata server we should maybe use a wsgi server or use oslo.services worker to spawn several processes
14:42:50 <ralonsoh> so this will be a limitation, for sure
14:43:35 <ralonsoh> this implementation uses the same strategy: haproxy with unix socket
14:43:45 <ralonsoh> and the metadata server listening to this socket
14:44:01 <ralonsoh> I'm now trying to export this to the L3 agent metadata
14:44:03 <ralonsoh> that's all
14:44:21 <ralonsoh> (btw, we don't have any CI testing metadata in DHCP)
14:44:42 <haleyb> so when oslo.service work progresses will there be something we can consume?
14:45:07 <ralonsoh> we'll need to implement something (I don't know what) to replace the multiprocess metadata
14:45:16 <ralonsoh> now is using eventlet.wsgi.server
14:45:23 <ralonsoh> I replaced all this logic
14:45:48 <ralonsoh> and most probably we'll be able to use the current logic to spawn processes using the new server
14:46:00 <ralonsoh> but still unknown if that will work
14:46:01 <haleyb> yes, it's a large patch, thanks for all the work on it
14:46:36 <haleyb> i did see one other change to use threading in the ovs agent i think
14:47:06 <haleyb> #link https://review.opendev.org/c/openstack/neutron/+/937765
14:47:13 <haleyb> i have not reviewed yet just watching
14:48:15 <haleyb> i need to prepare for another meeting so will move on
14:48:17 <haleyb> #topic on-demand
14:48:29 <haleyb> any other items to discuss?
14:48:48 <haleyb> oh, completely forgot about bug deputy...
14:49:08 <ralonsoh> I am this week
14:49:22 <haleyb> ralonsoh is covering this week, jlibosva next week, then obondarev
14:49:34 <haleyb> it should be very light with holidays i hope
14:49:52 <haleyb> and if some have to wait until january it will be Ok
14:50:28 <haleyb> ok, any other topics?
14:51:02 <haleyb> have a great week and enjoy the holidays, will see you in January
14:51:05 <haleyb> #endmeeting