07:01:32 #startmeeting swift 07:01:32 Meeting started Wed Jul 16 07:01:32 2025 UTC and is due to finish in 60 minutes. The chair is mattoliver. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:01:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 07:01:32 The meeting name has been set to 'swift' 07:01:41 whose here for the swift meeting 07:01:55 As always the agenda is at.. 07:02:02 #link https://wiki.openstack.org/wiki/Meetings/Swift 07:02:42 I was away last week on vacation so also haven't done much Swift stuff, so mostly info and a checkin with cschwede :) 07:02:50 #topic Bug triage 07:03:09 I've seen a bunch of bug emails 07:03:18 So you've been busy cschwede :) 07:03:40 Jupp, got back to some triaging earlier today. And rabbit holes! Was checking some bugs and code and this took way more time than expected... 07:04:01 Not sure if this strategy is sustainable. 07:04:48 During the triage I stumbled upon https://bugs.launchpad.net/swift/+bug/2058945 - this looks annoying, and looking at the linked issue it seems still not resolved. Anybody else seen this? 07:05:01 yeah, dont push it too hard. Maybe we should all be taking a peice of the work. 07:06:19 oh thats an interesting one. We have been having trouble in the past with high accep queues which starts to give timeouts to clients. 07:06:29 maybe somewhat related. 07:07:40 a bad client if they're doing pipelined requests slowly can also hold up a max_clients slot 07:08:30 I'll repond to the bug with what we ran into in the hopes its similar and we can lock something down. 07:09:03 Thanks, that would be great! 07:09:46 Checking the proxy accept queues is good practice when proxies or client requests start timing out.. I really should get the SO_TIMESPAMPING patch finished/landed :) 07:10:36 Keep up the good work cschwede and feel free to take a break from it if required. We should all probably be working through this backlog 07:10:53 #topic eventlet removal POC update 07:11:07 cschwede: I assume you've been stuck down other rabbit holes :P 07:11:53 Eventlet removal is a topic that comes up a bit here at Nvidia. 07:12:08 Yes, but still making slow progress. Though I also started to look into the object-server - we chatted about starting with the object-server first at the last PTG as well 07:12:26 kk 07:13:03 well if there is anything we can help with then let us know 07:13:23 I might need to speed up, getting looks from the family :P 07:13:36 sure, will do! 07:13:43 #topic October vPTG 07:14:12 Just a reminder that another virtual PTG is coming up in Oct 07:14:29 Oct 27-31 07:14:38 #link https://ptg.openinfra.org/ 07:15:02 timburke or I will make sure there is an etherpad to start gathering topics. 07:15:37 Already another one coming means I need to get my butt into gear and work on some of my projects :) 07:15:51 #topic aws-chunked 07:16:15 We need to make sure more of this chain is landed BEFORE the next upstream release 07:16:39 Because we don't want to release a half baked (even though it works) solution. 07:17:04 We should at least get the crc64-nvme stuff landed 07:17:20 #link https://review.opendev.org/c/openstack/swift/+/946141 07:17:38 jianjian has been reviewing and looking at this chain, so thanks! 07:17:52 I need to dig back in too. Esp now that I'm back from vacation. 07:18:10 #topic 2026.1 codename: Gazpacho 07:18:23 Speaking on the next upstream release, we have a name for it 07:18:38 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/QVZK5PFN233WNDX764B2NZ4W65U27FF4/ 07:19:05 Not much else to add there.. 07:19:18 #topic New ISA-L backend for liberasurecode 07:19:25 This one is interesting 07:19:34 #link https://review.opendev.org/c/openstack/liberasurecode/+/954285 07:20:00 Similar to isa_l_rs_vand / isa_l_rs_cauchy split, the only difference is the encoding matrix (which is then used to compute the wider encoding tables) 07:20:00 Related to Vandermonde matrices, but should avoid non-invertiblity 07:20:18 Interesting! 07:20:33 The bug seems to indicate the isa_l_rs_vand can have issues with parties > 5 07:21:12 So I think once this lands in liberasurecode we probably should add some kind of warning in swift if people use the current isa_l_rs_vand with > 5 parity 07:21:50 Let me paste more of Tims awesome discriptions from the agenda 07:21:58 Isnt' that already the case, mentioned in https://bugs.launchpad.net/liberasurecode/+bug/1639691 07:21:59 Related to Vandermonde matrices, but should avoid non-invertiblity problem from https://launchpad.net/bugs/1639691 07:22:11 #link https://launchpad.net/bugs/1639691 07:22:12 https://review.opendev.org/c/openstack/swift/+/468105 07:22:28 * cschwede should use #link more often. 07:22:41 oh nice 07:23:00 so already done.. and I+2ed it.. I fail at memory :P 07:23:23 Tim says: Seems to match encoding matrix used elsewhere, eg https://github.com/tahoe-lafs/zfec/blob/zfec-1.6.0.0/zfec/fec.c#L430-L479 07:23:33 #link https://github.com/tahoe-lafs/zfec/blob/zfec-1.6.0.0/zfec/fec.c#L430-L479 07:24:08 But the pressing question, other then testing and landing it is what name we should give it? 07:24:21 isa_l_rs_vand_inv? isa_l_rs_vand2? 07:24:57 if its backward compat with < 5 parity maybe replace.. but that might not be possible. 07:25:14 _inv might not mean much to people. maybe 2 is better. 07:25:33 Anything feel free to weigh in in the patch :) 07:25:38 That's all I got 07:25:49 #topic open discussion 07:26:33 I've still got a bunch of patches in the air.. but need to revisit them to see where they're at and I'm in a rush tonight.. so I got nothing else :P 07:28:12 Nothing else from my side as well today. Thanks Matt for running this! 07:28:30 Cool, nps. 07:28:46 I'll call it then. Thanks for coming and thanks for working on Swift 07:29:00 cschwede: so glad you catch up with you more regularly now! 07:29:04 #endmeeting