07:02:58 <mattoliver> #startmeeting swift
07:02:58 <opendevmeet> Meeting started Wed Jun  4 07:02:58 2025 UTC and is due to finish in 60 minutes.  The chair is mattoliver. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:02:58 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
07:02:58 <opendevmeet> The meeting name has been set to 'swift'
07:03:11 <mattoliver> hey cschwede
07:03:26 <cschwede> Hello mattoliver!
07:03:30 <mattoliver> As usual the agenda is at:
07:03:39 <mattoliver> #link https://wiki.openstack.org/wiki/Meetings/Swift
07:03:59 <cschwede> I don't have much news on #1 (bug triage) and #2 (eventlet), been on PTO
07:04:09 <mattoliver> I did update it, but most topics are really just quick updates
07:04:23 <mattoliver> fair enough, this might be a quick one then
07:05:01 <mattoliver> So we'll skip the first to topics but instead all hope cschwede had a PTO :)
07:05:07 <mattoliver> *two topics
07:05:25 <mattoliver> #topic SO_TIMESTAMP/SO_TIMESTAMPING patch
07:05:48 <mattoliver> Not to much on this really, but if I keep it in, it reminds me I need to work on it :P
07:06:10 <mattoliver> #link https://review.opendev.org/c/openstack/swift/+/944103
07:06:26 <cschwede> I think I can give that one a try on my side this week as well, if that helps
07:07:17 <mattoliver> Quickly looking at it, it's stuck on me it seems :P
07:07:31 <mattoliver> but yeah, your feed back would be great!
07:07:52 <mattoliver> Esp with the extra timeout I have in there. I had to do it, but is it worth is.. I think so, but happy to be wrong.
07:08:13 <mattoliver> #topic ringv2
07:08:15 <cschwede> I think this will be a very helpful feature for larger deployments to track things down
07:08:51 <cschwede> Well, both actually (timestamps+ringv2) ;)
07:09:09 <mattoliver> We've just enabled it in all of our prod clusters, and working great. We haven't crossed to the bigger dev_id bridge yet, but that'll probably be at the end of the month.. so will let everyone know how it goes
07:10:18 <cschwede> Sounds great actually!
07:10:22 <mattoliver> timburke just squashed a patch into it to go from using named tuples to dataclases.. so finally getting to use more modern py3 things (even if it was introduced in py3.7 :P)
07:11:34 <mattoliver> yeah, we'd tested it a bunch, even forced a rebuild of a wider dev_id ring and deployed it to a few racks just to check and make sure memory usage and everything else was working as expected in prod.
07:12:00 <mattoliver> All went great, so nvidia is now running it
07:12:19 <mattoliver> oh the link
07:12:24 <mattoliver> #link https://review.opendev.org/c/openstack/swift/+/834261
07:12:58 <cschwede> did you notice any big difference in memory usage at all?
07:14:39 <mattoliver> only what was expected.. but was a little less then expected.. we basically add 2 bytes for dev id in the replica2part2dev. so 2 * 2^partpower * replicas was back of the napkin.
07:15:44 <mattoliver> So should be worse in EC (more replicas) and when each worker of a services auto-reload the ring (after it's forked at startup).
07:16:12 <mattoliver> So initially they can all share the loaded ring. Then memory usage goese up a little as you replace the ring on a node.
07:16:56 <mattoliver> But I feel like it was less then I expected.. so went fine for us. I can find some numbers and pop then in IRC if people are interested.
07:17:30 <cschwede> no worries, i was just curious. and less than expected sounds good!
07:17:56 <mattoliver> #topic aws-chunked
07:18:06 <mattoliver> #link https://review.opendev.org/c/openstack/swift/+/944073
07:19:00 <mattoliver> I think this is ready for reviews again. And we need to land this before the next swift release, because it'll actually allow us to support the extra algorithms given to us :P
07:19:16 <mattoliver> ie, so we can actually check the crc checksums.
07:19:42 <mattoliver> I started looking, so I need to finish reviewing it.
07:20:05 <mattoliver> No much else for that topic
07:20:16 <mattoliver> #topic swiftclient release
07:20:29 <mattoliver> Well it was released
07:20:37 <mattoliver> That's basically that update :P
07:20:43 <cschwede> \o/
07:21:05 <mattoliver> Last 2 topics I just added not long ago.
07:21:14 <mattoliver> #topic Coop tokens
07:21:24 <mattoliver> #link https://review.opendev.org/c/openstack/swift/+/908969
07:21:48 <mattoliver> We've been carrying this and running it in prod for like a year or so, and it's awesome.
07:21:53 <mattoliver> We talked about it at the last PTG
07:22:23 <mattoliver> jianjian has been cleaning it up and getting it ready to actually merge. And I think we should.
07:22:45 <cschwede> Well, if you run it like a year in prod, it sounds pretty good, no?
07:23:02 <mattoliver> yeah, exactly
07:23:09 <mattoliver> cant ask for more testing :P
07:23:20 <cschwede> right :)
07:24:23 <mattoliver> As it currently stands it helps shard range caches and stops a thundering herd problem. So everyone should benefit if they run sharding.. but we probably could move it to more caching areas.
07:25:06 <mattoliver> basically just wan't to shout it out to everyone, to give kudos to jian and say we need to review it. (mostly talking to myself there).
07:26:03 <mattoliver> Last topic on the agenda I have, is basically because of Tims comments in channel earlier
07:26:10 <mattoliver> #topic Move to pyproject
07:26:35 <mattoliver> #link https://review.opendev.org/c/openstack/pyeclib/+/947543
07:27:18 <mattoliver> Tim's been testing stuff on a mac for some reason. And things can't currently build.
07:27:58 <mattoliver> To quote tim above: "we should maybe think about merging that pyproject.toml pyeclib change -- wheel building on OS X is currently busted (at least for me) and in such a way that setup.py doesn't even realize it's running on a mac
07:27:58 <mattoliver> that particular part seems to trace back to platform.platform() returning something like "macOS-..." instead of "Darwin-..."
07:27:58 <mattoliver> but even addressing that, our existing setup.py doesn't seem to properly respect CFLAGS/LDFLAGS, so it couldn't find my custom libec install location. the switch to pyproject.toml (and with it, getting out of setuptools' way a bit) fixed that, though!"
07:28:10 <mattoliver> Not sure how that comes out, but there it is :P
07:28:38 * cschwede looking at this right now
07:29:05 <mattoliver> There is still a setup.py so things on older systems should still build fine so long as there is a new enough setuptools.
07:29:22 <mattoliver> I guess I could go double check this on some old systems I'm still building for.
07:29:47 <mattoliver> Cough centos7 cough
07:29:55 <cschwede> you added the s3api xml files manually in your .spec, right?
07:30:27 <mattoliver> Yeah, I did to get around the other issue.
07:30:37 <mattoliver> although maybe we should think about landed the MANIFEST revert change
07:31:00 <mattoliver> Though I think later setuptools probably does the right thing, so maybe not.
07:31:18 <mattoliver> But put it into our spec file, as it doesn't hurt to make sure the files are there.
07:32:08 <cschwede> right
07:32:30 <mattoliver> It's getting too late to me to play with it today. But I'll attempt a build on our centos7 env with the pyproject change tomorrow and put the results as a comment.
07:33:59 <mattoliver> ok, so according to the pyproject.toml we need `setuptools>=74.1`
07:34:56 <mattoliver> So thats what we need to check. or also put in requirements maybe 🤷
07:35:17 <mattoliver> oh that's pyeclib I have there... is that the one he means.
07:35:34 <mattoliver> yup it was, good
07:35:48 <mattoliver> Anyway, that's all I got
07:35:59 <mattoliver> #topic open discussion
07:36:06 <mattoliver> Anything else to bring up this meeting?
07:36:20 <cschwede> Not from my side, thx mattoliver for all the updates!
07:36:42 <mattoliver> KK, might close the meeting then!
07:36:52 <mattoliver> Thanks from coming and thanks for working on swift!
07:36:52 <mattoliver> #endmeeting