21:00:55 <timburke> #startmeeting swift
21:00:55 <opendevmeet> Meeting started Wed Mar 26 21:00:55 2025 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:55 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:55 <opendevmeet> The meeting name has been set to 'swift'
21:01:02 <timburke> who's here for the swift meeting?
21:01:08 <zaitcev> o/
21:01:17 <kota> o/
21:03:04 <timburke> sorry about dropping the last couple meetings
21:03:14 <timburke> but i did at least update the agenda for today!
21:03:25 <timburke> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:03:29 <timburke> first up
21:03:32 <timburke> #topic PTG
21:03:56 <timburke> it's coming up! less than two weeks away!
21:04:18 <timburke> thanks to everyone who's responded on the meeting-time poll
21:04:21 <timburke> #link https://framadate.org/LBfzMX2I4C1JL9cZ
21:05:00 <timburke> if you haven't yet, please do -- i'll try to get slots booked this week or early next
21:05:54 <timburke> our etherpad for the PTG is looking rather bare
21:05:57 <timburke> #link https://etherpad.opendev.org/p/swift-ptg-flamingo
21:06:44 <timburke> if you have discussion topics, please add them -- i'll try to do the same (at the very least, i know we ought to include ring-v2, labeled metrics, aws-chunked)
21:07:48 <timburke> speaking of...
21:07:51 <timburke> #topic aws-chunked
21:08:35 <timburke> we decided to lean into verify-but-don't-write-down for client-provided checksums
21:08:54 <timburke> #link https://review.opendev.org/c/openstack/swift/+/944073
21:10:11 <timburke> this gets us something that we can feel reasonably good about (we won't store data that doesn't match the client-provided checksum) without needing to solve the larger how-do-we-persist-this-and-get-it-into-listings questions
21:10:16 <timburke> (at least, not yet)
21:12:00 <timburke> there are still some concerns around the work, though; in particular, as we were getting closer to using it in prod, we realized that the slow, pure-python fallback versions of some CRCs might present a denial-of-service vector, especially if your proxy layer is CPU-constrained
21:12:29 <timburke> (which tends to be the case, especially with EC and encryption)
21:13:06 <zaitcev> If we also compute and verify MD5, then client-provided checksums are for transmission only and integrity is maintained. They are okay not to store.
21:14:02 <timburke> that was our conclusion, too -- nice to have (so clients can request them and use them for local verification), but not strictly necessary
21:14:38 <timburke> so i'm looking at alternatives -- anycrc seem promising
21:14:41 <timburke> #link https://pypi.org/project/anycrc/
21:15:40 <timburke> and it also provides a way to combine partial CRCs, which will be useful for when we *do* implement full s3api-additional-checksum support
21:15:49 <timburke> but...
21:16:29 <timburke> 1. it would be a new requirement (not just for us, but for openstack/requirements)
21:16:33 <timburke> 2. no distros currently package it
21:17:00 <timburke> and 3. it's py37+, while we currently support down to py36
21:19:36 <timburke> but as a cython wrapper over a pared-down vendored version of crcany, it seems like it ought to be "fast enough"
21:19:40 <timburke> #link https://github.com/madler/crcany/
21:21:15 <timburke> speaking of supported python versions...
21:21:19 <timburke> #link supported python versions
21:21:33 <timburke> i realized that we already made a decision last PTG
21:21:47 <timburke> "We'll declare next cycle release as our last supporting py36/py37 (but may let jobs linger like we did for py27)"
21:22:13 <timburke> oops :-( i didn't do that for 2.35.0
21:23:59 <timburke> so: do we want to continue supporting py36 & py37 for flamingo, or should i just drop them sooner rather than later and be sure to declare the lack of support in the next release?
21:27:08 <zaitcev> It's a difficult question for me, because I'm tired on py36, but it's still around as long as RHEL 8 clones are around (e.g. Oracle).
21:29:02 <timburke> at the same time, there's a real question of how likely someone on a RHEL 8 clone is to want to upgrade all the way to latest-release
21:29:49 <timburke> (i say as someone still stuck on a RHEL 7 clone... but we don't use the distro-provided python anyway!)
21:33:00 <timburke> well, it's something to think about, anyway. another topic for the PTG
21:33:10 <timburke> that's all i've got for this week
21:33:16 <timburke> #topic open discussion
21:33:24 <timburke> anything else we should talk about this week?
21:34:34 <zaitcev> Not here.
21:34:44 <zaitcev> Not from here, I mean.
21:34:49 <kota> me too.
21:35:05 <timburke> all right, we'll call it early then
21:35:18 <timburke> thank you all for coming, and thank you for working on swift!
21:35:22 <timburke> #endmeeting