21:00:06 <timburke> #startmeeting swift
21:00:06 <opendevmeet> Meeting started Wed Aug  6 21:00:06 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:06 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:06 <opendevmeet> The meeting name has been set to 'swift'
21:00:15 <timburke> who's here for the swift meeting?
21:00:27 <mattoliver> o/
21:02:05 <timburke> sorry i skipped the meeting a couple weeks ago -- i think i just got busy and forgot
21:02:23 <timburke> thanks for keeping the rhythm going for the 0700 meeting, though, mattoliver!
21:02:35 <timburke> as usual, the agenda's at
21:02:38 <timburke> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:02:38 <mattoliver> Nps, it happens
21:02:57 <timburke> first up
21:03:05 <timburke> #topic vPTG
21:03:30 <timburke> just another quick reminder on the vPTG in a couple months
21:03:51 <timburke> i think i'll keep the topic there at least until i actually get an etherpad up to gather topics ;-)
21:04:11 <timburke> next up
21:04:16 <timburke> #topic ring v2
21:04:33 <timburke> the big hairy new-format patch landed!
21:04:48 <timburke> thanks mattoliver and clayg for reviewing it
21:05:19 <timburke> now we get to do the even-more-interesting bits ;-)
21:05:21 <mattoliver> Yeah, I decided to take advantage of the clay +2 and comments. And decided to land it and figured anything else can be follow ups
21:05:30 <mattoliver> +100
21:06:28 <timburke> there were a couple rough edges that i wouldn't have minded smoothing out -- but at the same time, i'm not sure i could have without breaking our prod clusters that were already using it :-(
21:06:49 <timburke> or at least, not easily
21:07:00 <mattoliver> Sorry if I jumped the gun a little then
21:07:53 <timburke> eh, no worries. i was feeling stuck -- at least now, the path forward if i want to fix them is more clear (do the tricky thing, so i don't break other people's clusters, too)
21:08:13 <timburke> next up
21:08:22 <timburke> #topic new backend for liberasurecode
21:08:31 <timburke> the libec change is looking good
21:08:42 <timburke> #link https://review.opendev.org/c/openstack/liberasurecode/+/954285
21:08:52 <mattoliver> just the name
21:09:13 <timburke> and i haven't heard anyone offer better names for it -- if that continues to be the case, i'm inclined to merge it by the end of the week
21:09:47 <mattoliver> yeah, fair enough, sounds like a good plan
21:09:57 <timburke> there's also a corresponding patch for pyeclib to support it
21:09:58 <mattoliver> I'll keep my naming thinking hat on
21:10:00 <timburke> #link https://review.opendev.org/c/openstack/pyeclib/+/956109
21:10:22 <opendevreview> Merged openstack/swift master: crypto: Fix traceback on non-utf8, non-swift paths  https://review.opendev.org/c/openstack/swift/+/953623
21:11:01 <timburke> (needs a little more, but on the whole i've been pleased by how simple it is to add new backends there)
21:11:58 <timburke> next up
21:12:05 <timburke> #topic type hinting in pyeclib
21:13:45 <timburke> so while i was poking around in pyeclib, and exchanging review comments about how swift now has some (not-checked) type hints in it, i got to thinking about how we'd want to go about using and enforcing type hints, and thought pyeclib would be a decent place to start
21:14:58 <mattoliver> Well it's a smaller codebase so could be a good place to start and test I guess
21:15:21 <timburke> yup: it's small, self-contained, has no dependencies...
21:15:42 <timburke> so i spent a day or so trying it out, eventually landing on a chain that ends with
21:15:53 <timburke> #link https://review.opendev.org/c/openstack/pyeclib/+/956612
21:16:32 <mattoliver> kk, will take a look
21:17:06 <timburke> there were definitely a few bugs caught as a result! i tried to structure the chain so we have the functional changes in the fron, then a patch that just adds annotations, then a patch to fix up packaging
21:17:54 <timburke> first two patches are definitely ready to take a look at; last two still need a little work, though
21:18:15 <mattoliver> kk
21:18:46 <timburke> but getting a pyi file at the end of it all that describes the interface for pyeclib_c (the C extension) was pretty nice!
21:19:49 <timburke> as i got in there, i realized there was a decent bit of cruft, though, which brings me to...
21:20:01 <timburke> #topic removing dead interfaces from pyeclib
21:21:36 <timburke> we've got some weird warts in pyeclib. there's an ECStripingDriver that basically tries to mimic RAID 0, and an ECNullDriver that i guess was used for benchmarking?
21:22:58 <mattoliver> yeah, I assumed the null driver was for something like that
21:23:09 <timburke> i suspect both of them were added to demonstrate the library_import_str interface for ECDriver -- they're certainly the only known users of it
21:23:44 <timburke> but the striping driver doesn't even work with ECDriver! stripes require m=0, while ECDriver requires m>0
21:25:06 <timburke> and then check_metadata seems weird -- it requires that you pass in *all* of the frags (data and parity)
21:25:22 <timburke> i kinda want to just rip all of that out
21:25:56 <timburke> and probably do a v2 bump for the library
21:26:47 <timburke> wanted to start shopping the idea, and get input on whether i ought to try to start emitting deprecation warnings about it now
21:27:31 <mattoliver> right, so one doesn't work and the other is clearly a noop. so yeah they're obviously not used.
21:28:46 <timburke> i mean, i guess someone could try to instantiate the striping guy directly -- but i don't know why anyone would want it, since it can only harm durability
21:30:55 <mattoliver> I guess one could, I wonder if there is a git entry with info when it was added. ..but I don't see a harm  in a dep warning. Seems like as good time as any.
21:31:29 <timburke> 👍
21:31:56 <timburke> ok, one last-minute topic
21:32:00 <timburke> #topic releases
21:32:37 <timburke> i'm inclined to do libec and pyeclib releases shortly after getting the new backend patches merged
21:33:11 <timburke> and i also started putting together release notes for a swift release (though a few more things have merged since i last updated it)
21:33:31 <timburke> #link https://review.opendev.org/c/openstack/swift/+/956333
21:34:13 <timburke> i'll be out next week, so if i don't get to them this week, it might be more like two ;-)
21:34:26 <mattoliver> definitely!
21:34:39 <timburke> but i'd appreciate eyes on the release notes if anyone has a chance
21:34:45 <timburke> that's all i've got
21:34:46 <mattoliver> do we want to merge your ringv2 followup before the swift release?
21:35:12 <mattoliver> I'll definitely give it a read.
21:36:20 <timburke> maybe? see what you think. part of it makes things more brittle (by blowing up on unrecognized checksums) which might complicate things a little. but clayg seemed to like the idea, i think?
21:36:30 <timburke> #topic open discussion
21:37:02 <timburke> anything else we should bring up this week?
21:38:49 <mattoliver> I had a patch to add a past2timestamp structure in with the history table stuff... but instead am thinking about just moving the past_past_moves and past_part_moves_epoch in, which basically give a similar answer.. except to the hour grainulatity for older part moves.
21:39:50 <mattoliver> the hour granularity might be good enough 🤷 Plus it moves an existing builder structure into the ring.
21:40:04 <mattoliver> Anyway, just playing for now. I see how it shakes out
21:40:06 <timburke> nice -- yeah, i was thinking i should take a look at the state of the history patch and think about where we want to go with it
21:41:02 <timburke> oh yeah, i got the gate passing for those backports of the aws-chunked/validate-checksums-on-upload work: https://review.opendev.org/q/project:openstack/swift+branch:stable/2025.1+is:open
21:41:11 <mattoliver> yeah, that'll be great if you get the chance. Now's the time to change things on it.
21:42:29 <mattoliver> It does feel weird, orig wrote it so long ago it feels like a different me, so keep playing with it to see if there are other possible improvements. I'd also like to go revisit the reconstructor changes to see if they still make sense.
21:42:29 <timburke> how do we feel about those stable patches? it might be stretching the scope for stable a little, but zigo indicated it'd be nice to have
21:43:00 <timburke> mattoliver, yeah, i know that feeling
21:44:39 <mattoliver> yeah, I'd say it might be stretching a little. but the fact that it fixes boto based clients and because zigo  wants it, I say let's backport em ;)
21:45:23 <zigo> Yeah, as more and more software relly on the aws-chunked, it is a pain especialy because of boto indeed.
21:46:20 <timburke> all right, i'll look at getting that merged then, and add a stable release to the list of things i oughta get out there ;-)
21:47:18 <zigo> If backported, there's a chance I can push it as a Debian Stable proposed update, otherwise no hope until Debian 14 (hint: Debian 13 is to be released this week-end).
21:47:51 <mattoliver> nice, then let's get it in ;) thanks for getting them together timburke
21:48:11 <timburke> sounds good -- thanks for keeping us aware of downstream impacts, zigo!
21:48:23 <zigo> 2 more years without proper S3 support does not feel nice...
21:48:46 <timburke> all right, i think i'll call the meeting a little early, let matt get an extra ten minutes in his morning
21:48:56 <timburke> thank you all for coming, and thank you for working on swift!
21:49:01 <timburke> #endmeeting