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