14:00:23 #startmeeting networking 14:00:23 Meeting started Tue Sep 24 14:00:23 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:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:23 The meeting name has been set to 'networking' 14:00:26 Ping list: bcafarel, elvira, frickler, mlavalle, mtomaska, obondarev, slaweq, tobias-urdin, ykarel, lajoskatona, jlibosva, averdagu, amotoki, haleyb, ralonsoh 14:00:29 \o 14:00:32 o/ 14:00:33 o/ 14:00:38 \o 14:00:45 o/ 14:00:47 o/ 14:01:35 #topic announcements 14:01:39 o/ 14:01:41 lets get started 14:02:08 RC1 has been released, we have identified a few fixes and I will propose an RC2 right after this meeting 14:02:16 September 26th, 2024 is the deadline for final 2024.2 Dalmatian release candidates 14:02:23 so I'm hoping RC2 is the last 14:02:30 We will then enter a quiet period until we tag the final release on October 2nd, 2024 14:02:36 Watch for any translation patches coming through on the stable/2024.2 branch and merge them quickly 14:02:43 o/ 14:02:55 o/ 14:02:55 Release-critical bugfixes will need to be merged in the master branch first, then backported to the stable/2024.2 14:03:08 Master branch has switched to 2025.1 Epoxy development, but please prioritize any work necessary for completing 2024.2 Dalmatian plans 14:03:26 It's time to start planning the 2025.1 Epoxy development cycle, including discussing PTG sessions content, in preparation of Project Teams Gathering 14:03:35 are we going to use the priority list to mark what needs to be reviewed? 14:03:38 I will start on that next week 14:04:45 mlavalle: yes, we can continue to use that, but for RC* ping in the channel might be quicker with the timeline 14:05:09 ack, ping me if necessary 14:05:30 at this point I think RC2 will be it, and I believe it's all been merged to stable/2024.2 14:06:54 to throw a wrench in it I'm mostly out the rest of the week, will only be checking email sporadically, so please use that (old) communication style if you need me 14:08:39 ok... any question on that? 14:08:41 * mlavalle is not sure email is older than irc 14:09:05 well i won't be available over nntp either :-p 14:10:14 my daughter was so happy to tell us she'd been sending a lot of emails lately, kids today use snapchat for everything 14:10:32 so i'm old 14:10:35 LOL, yeap 14:12:04 :) 14:13:27 my only other announcement was I started doing the normal beginning of cycle patches for updating the gate jobs 14:13:35 https://review.opendev.org/q/topic:%222025.1-neutron-jobs%22 14:13:40 thanks 14:13:51 one of those is waiting on a zuul-jobs patch still i think 14:14:16 actually, one is an openstack-zuul-jobs patch, but there is another dependency 14:14:29 also note that devsstack hasn't branched yet, so jobs may still be missing 14:14:49 (for stable/2024.2) 14:15:00 either way, it's good to get those in early so any reviews are great 14:15:24 frickler: oh, like grenade probably 14:15:47 yes, same thing for grenade 14:16:14 most of the patches I did were just to move python versions forward and enable our skip-level job 14:16:24 haleyb: what's the minimal py version now? 14:16:55 py3.9 is minimal, py3.12 is maximal (?) the ones in-between are now peridoc 14:17:05 was it py38 before? 14:17:50 yes, we had py38 14:17:55 https://review.opendev.org/c/openstack/neutron/+/929788 has a link to the governance doc, but was only 3.9 before 14:18:38 ack; of new syntax, probably just dict1 | dict2 instead of dict1.copy(); dict.update() is now useful to us 14:18:40 https://review.opendev.org/c/openstack/governance/+/926150/3/reference/runtimes/2025.1.rst 14:20:43 anyways, that's all the announcements I had 14:21:15 #topic bugs 14:21:30 jlibosva was the bug deputy last week, his report is at 14:21:39 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/K64H67NE3OJGL73AL5KL33AFXWDKUWIY/ 14:22:27 the first we knew about since the other day 14:22:34 #link https://bugs.launchpad.net/neutron/+bug/2081173 14:22:44 security-groups-rules-belongs-to-default-sg slows down SG GET operations 14:23:36 it was related to another bug filed last week, which i don't see in this list 14:24:25 maybe because the other was already fixed/ 14:24:43 right, but should still be in the list 14:24:47 just had to find it 14:24:51 #link https://bugs.launchpad.net/neutron/+bug/2081087 14:24:58 Performance regression in neutron-server from 2023.1 to 2024.1 when fetching a Security Group 14:25:43 ralonsoh fixed that and we backported, but more work is required on other places that could benefit from using 'selectin' 14:26:01 where's the "more work" tracked? 14:28:10 ihrachys: i need to open another bug for investitagion, will take some benchmarking of each case to figure out 14:29:42 yeah at the very least some investigation tracker. we have one for rally scenarios check-up (also in the list) but not for selectin 14:30:23 right. the patch I created to change them all is at least a roadmap 14:30:26 #link https://review.opendev.org/c/openstack/neutron/+/929851 14:30:38 but it shouldn't merge as there are cases where it makes things slower 14:31:37 So i will create one, and i was going to add it to the PTG list 14:32:10 the next one is related 14:32:14 #link https://bugs.launchpad.net/neutron/+bug/2081108 14:32:19 Merged openstack/ovn-bgp-agent master: Drop Python 3.6/7 support https://review.opendev.org/c/openstack/ovn-bgp-agent/+/930110 14:32:20 Merged openstack/ovn-bgp-agent master: Bump hacking https://review.opendev.org/c/openstack/ovn-bgp-agent/+/930111 14:32:22 Tighten / improve rally SG tests to catch performance regressions 14:32:53 when we saw the regression, it seems like rally should have triggered something 14:33:43 i'm just not sure it's setup to find these things, for example, i think it only adds 20 SGs 14:34:09 so if we can automate something better it would be good 14:34:37 maybe it should add 1000 and have more tight thresholds 14:34:42 the bug is open ended, yes 14:35:02 +1 to have jobs for perf tests perhaps as periodic or similar 14:35:34 of course now i can get on my soap box and say we should get better at asking for perf numbers on DB patches, since the person making the change is probably best suited to providing them 14:35:40 I don't think rally can compare somehow results with older runs 14:35:57 slaweq: it compares with a hardcoded threshold I think 14:36:07 That would be imho good to check and raise failures if there is regresion 14:36:11 so put threshold at x2 what you observe; then you catch x20 regressions 14:36:59 I suspect one could with enough motivation build some chart from collected rally results that would show trends. 14:37:07 Worth to try for sure 14:37:57 haleyb: ++ on being more anal / conservative about touching db layer and other foundational parts 14:38:08 I think Ironic has some job where they have simple script to create many resources with API and measure time of responses but I would need to check that to be sure 14:39:15 ihrachys: i know on kernel netdev there is usually a lot of data in the commit message when a "this is faster/better" change is proposed 14:39:35 maybe a good conversation for the ML so we don't reinvent the wheel 14:40:07 seems like common sense to add relevant data / explanations to commit messages... not sure what to "reinvent" here except culture? 14:41:32 in this scenario though, I think the regression was introduced by a new api, no? no one claimed it's "faster". it was a functional change that regressed something else. 14:42:16 ihrachys: yes, but there was still a new lazy='joined' if i'm remembering correctly 14:43:48 typically it's a distro user that finds these regressions, at least it seems that way to me, and that means a years-old change, etc 14:44:51 reviewers should definitely pay attention to these things (among lots of other things); yes. but I feel most active reviewers on the project are quite stretched so quality necessarily suffers. it's also a strain on contributors to collect all the requested data, run all the tests etc. etc. 14:45:39 ihrachys: and yes, part is culture, my reinvent comment was more aimed at if other services are somehow doing this already 14:45:57 it never hurts to ask around :) 14:46:35 i mean, can there be a job that does a before/after with a single patch? that's one way 14:46:47 anyways, this is perfect fodder for the PTG :) 14:46:59 +1 for PTG discussion 14:47:24 i will get an etherpad created, etc so i don't forget all these things 14:49:01 that was it for high bugs, any others to discuss? 14:50:00 #topic community-goals 14:51:03 i think there is only one of the initial eventlet changes left 14:51:07 #link https://review.opendev.org/q/topic:%22bug/2069581%22 14:51:50 the tempest patch blocking it merged, but need to wait for rodolfo to go through the latest run on that one 14:52:59 #topic on-demand 14:53:17 i did forget to mention, obondarev is the bug deputy this week, ralonsoh is next week 14:53:26 hopefully not many bugz 14:53:39 on it, not many so far :) 14:53:50 nice 14:53:55 any other topics? 14:54:35 ok, have a nice week, i'll get RC2 proposed 14:54:38 #endmeeting