14:00:10 #startmeeting networking 14:00:10 Meeting started Tue Jan 7 14:00:10 2025 UTC and is due to finish in 60 minutes. The chair is mlavalle. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:10 The meeting name has been set to 'networking' 14:00:16 Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki, haleyb, ralonsoh 14:00:26 o/ 14:00:29 hello 14:00:30 \o 14:01:26 o/ 14:01:38 hi all 14:01:57 #announcements 14:02:13 #link https://releases.openstack.org/epoxy/schedule.html 14:02:24 o/ 14:02:32 We are currently in week R-12 14:02:48 o/ 14:03:02 and it is the Epoxy-2 milestone 14:03:02 o/ 14:03:06 Sahid Orentino Ferdjaoui proposed openstack/neutron master: common: fix wait_until_true to support native thread https://review.opendev.org/c/openstack/neutron/+/937843 14:03:07 Sahid Orentino Ferdjaoui proposed openstack/neutron master: ovs: remove the usage of eventlet in the OVS agent https://review.opendev.org/c/openstack/neutron/+/937765 14:03:59 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:05:40 and haleyb|out wants us to continue using the priorities dashboard for patches in the "ready to merge" state (weekly reminder) 14:07:11 Finally, have a very sucessful and happy 2025 14:07:22 Any other announcements? 14:08:19 mlavalle: +1 for 2025, and Happy New Year everybody :-) 14:08:53 HNY! 14:09:11 late o/ 14:09:43 #topic Bugs 14:09:44 HNY all :) 14:10:57 Last week the bug deputy was obondarev and the one before it was jlibosva's turn 14:11:20 but apparently nobody told them, since I didn't see any emails from them 14:11:53 so last report we have is from ralonsoh: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/STPSYHHAAYJTJFD4DBWAAC2L2M2MUEM2/ 14:12:15 in any case, tomorrow morning I'll send a report for the last 2 weeks 14:12:21 anything you want to highlight ralonsoh from that report? 14:12:25 we need to keep the list updated 14:12:45 no, we have 1 bug not assigned 14:12:49 https://bugs.launchpad.net/neutron/+bug/2092174 14:12:55 but this is not a priority 14:13:07 anyone is welcome to take it 14:13:23 and, as commented, tomorrow morning I'll send an updated bug mail 14:13:47 We have 9 bugs accumulated since the last report, starting with https://bugs.launchpad.net/neutron/+bug/2092407 14:13:51 I can take it for sure, but this should be maybe discussed first within the team 14:14:41 maybe others don't want to deprecate this config option, maybe there is some use case for it which I am not aware about 14:15:33 how about sending a message to the ML and then discuss it in the drivers meeting? 14:15:47 mlavalle sure, I will do that 14:15:59 +1 14:16:05 and will add this to the Friday's meeting agenda 14:16:46 +1 for mail 14:17:43 I would say give a couple of weeks between the message to the ML and discussion in the drivers meeting. That way we give opportunity to the community to give feedback 14:18:07 ++ 14:18:19 cool 14:18:43 anything else we should discuss in this section? 14:20:26 this week the bug deputy is ralonsoh and next it is lajoskatona's turn. you both ok with it? 14:20:36 yes 14:20:59 ack 14:21:24 #topic community goals 14:21:48 anything new on on neutronclient deprecation ? 14:22:35 yes I work on a patch for horizon fips 14:22:42 so slow progress 14:22:53 https://review.opendev.org/c/openstack/horizon/+/938488 14:23:12 that's it for this topic 14:23:43 thanks for the update lajoskatona ++ 14:24:15 the other subject here is eventlet. Any updates this week? 14:24:21 yes, several 14:24:33 documentation for eventlet deprecation (review): https://review.opendev.org/c/openstack/neutron/+/938390 14:24:57 OVN agent with a new socket server implementation (see limitations): https://review.opendev.org/c/openstack/neutron/+/937545 14:25:01 this server does not use eventlet 14:25:19 remember OVN agent is the default agent for plugin jobs 14:25:22 next one 14:25:30 OVN metadata agent: https://review.opendev.org/c/openstack/neutron/+/938393/ 14:25:49 same as before, and I've refectored a bit the agent not to use oslo.services (for now) 14:25:56 and now it is running without eventlet 14:25:59 next one 14:26:14 L3 thread processing reduction: https://review.opendev.org/c/openstack/neutron/+/938406 14:26:17 it failed CI. Is it due to the change? 14:26:24 mlavalle, which one? 14:26:33 metadata 14:26:58 I need to check but most probably not 14:27:08 ack 14:27:11 ovn job is not stable since we migrated to wsgi 14:27:15 there are several bugs open 14:27:21 and I'm trying to address all of them 14:27:44 I'm checking the logs 14:27:49 this is related to this bug 14:28:01 --> https://review.opendev.org/c/openstack/neutron/+/938319 14:28:16 so continuing with the list of patches 14:28:24 L3 thread processing reduction: https://review.opendev.org/c/openstack/neutron/+/938406 14:28:35 Hi people, is it possible that this configuration... (full message at ) 14:28:38 please review and check Liu's comment 14:28:50 this is the same as with the DHCP patch 14:29:04 multithread does not improve the event processing performance at all 14:29:15 yeap 14:29:18 and once we move to kernel threads that are preemptive 14:29:29 we can have the problem of stopped threads to start processing others 14:29:47 so we can have routers not fully initialized and the L3 agent processing others 14:29:57 and that's all for today 14:30:33 Thanks for the update and the hard work on this topic ralonsoh ++ 14:31:02 another batch of patches from Sahid; https://review.opendev.org/q/topic:%22bug/2087939%22 14:31:08 yes 14:31:10 mostly for os-ken 14:31:23 I think I had a topic for it in next section 14:31:29 but let's discuss this it here 14:31:31 the point is 14:31:59 I'll change topic 14:31:59 if we can't migrate os-ken to kernel threads in this cycle, I would suggest to go back again to ofctl 14:32:02 #topic on-demand 14:32:19 now, os-ken has one single implementation, eventlet 14:32:37 and the effort to migrate to kernel threads is unknown 14:32:51 so if this is not possible in a reasonable amount of time 14:33:16 I would suggest restoring ocftl (that works and must do it with kernel threads) 14:33:30 but this is just a heads-up 14:33:40 ralonsoh: but is that not enough to remove the monley patching event if we keep the implemntation using eventlet? 14:33:43 https://review.opendev.org/c/openstack/os-ken/+/938337 14:34:13 at least for this release? 14:34:20 sahid_, where are you removing the monkey patching? 14:34:29 this is being called from the ovs agent 14:34:37 and we monkey-patch before calling it 14:34:49 did you check that with any neutron CI? 14:34:55 the function hub.patch is doing the monkey patching is osken lib right? 14:34:56 ralonsoh: what is ocftl? 14:35:15 the CLI interface, using "ovs-ofctl" commands 14:35:23 ralonsoh: it's basically on what i'm currently working 14:35:36 lajoskatona: asked me to use a dep patch with neutron 14:35:48 https://review.opendev.org/c/openstack/os-ken/+/938337 14:35:49 sahid_, perfect, so I'm just saying that this is an alternative to os-ken, if the migration is not possible 14:36:02 ralonsoh: great 14:36:03 ralonsoh: ahh, ok 14:36:19 sahid_, this patch and the CI job is using eventlet 14:36:30 --> https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_7dd/938337/2/check/neutron-ovs-tempest-dvr/7ddc386/controller/logs/screen-q-agt.txt 14:36:40 so this is not a valid test 14:37:00 i have not checked at that point 14:37:44 but i don't see any reason that osken with its current implementation to not work without monkey patch 14:37:56 i will elt you know 14:38:29 because the os-ken hub has one single implementation, that is based in eventlet 14:38:35 yeah, os-ken has lots of modules used by neutworking projects (BGP and similar protocol files) so even if we drop hub we have to keep the rest I beleive 14:38:50 and you need the os-ken hub to spawn the threads: one for the agent, one for the commands and one moniting the OF table 14:39:05 but it is not possible to drop the hub 14:39:15 ralonsoh: yes but that implementation can with and without monkey patch 14:39:22 can work 14:39:41 that is said I don't have any issue to remove osken at all 14:39:48 perfect then, waiting for a CI job testing that 14:39:55 os-ken is much faster than osctl 14:39:57 ofctl 14:40:07 that will be a serious regression in performance 14:40:32 interesting point, thanks 14:42:08 btw I'm trying different king of impl to fix wait_until_true I will be glad to get any idea of which one could be the best 14:42:11 https://review.opendev.org/c/openstack/neutron/+/937843/9 14:42:43 ion that one I run the predicate in a separate thread instead of making it runnoing in the main thread and having a timer in a different thread 14:42:57 but it's an other topic, sorry for the disruption 14:43:17 anything else to discuss today? 14:43:26 not from me 14:43:55 I added one topic for on-demand 14:44:21 go ahead, lajoskatona 14:44:26 There was a self +2 wf+1: https://review.opendev.org/c/openstack/neutron/+/936235 14:44:48 and I think this is a topic to discuss and see how to void such situation 14:45:25 one side as I see is that there can be frustration for slow review even no-review 14:46:21 lajoskatona, anyone can participate in this meeting and request for reviews 14:46:24 but in this case this patch I copied was not dying in gerrit for months, so I believe that after the vacation time there would have been review for it 14:46:29 or send a mail 14:46:40 or increase the review priority 14:46:49 ralonsoh: +1 that is also true, and we have the priority board also 14:47:25 and, to be honest, I now have technical questions about this patch 14:47:35 so wanted to highlight this event and ask everybody to thin kabout it and when haleyb is back we can have some actions or more discussion around it 14:47:38 I'm of the opinion that this shouldn't be allowed 14:47:57 we can revert it and start the review again 14:48:12 I say let's do it 14:48:56 haleyb|out will be back tomorrow. he can do it 14:48:56 We can ask Liu to participate on a meeting and discuss this topic to see why was this the only solution He saw at that time 14:49:36 mlavalle: yeah let's wait till the boss is back :-) He commented on the patch so has context for it 14:49:49 ++ 14:50:18 that's it from me 14:50:20 thanks lajoskatona for bringing this up. really important 14:51:16 and I think that the proposal to let Liu voice his point of view is good 14:51:34 anything else for today? 14:53:13 ok, have a great first week of 2025! 14:53:26 #endmeeting