21:00:31 <timburke> #startmeeting swift
21:00:31 <opendevmeet> Meeting started Wed Apr 30 21:00:31 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:31 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:31 <opendevmeet> The meeting name has been set to 'swift'
21:00:39 <timburke> who's here for the swift meeting?
21:00:54 <mattoliver> o/
21:01:36 <timburke> as usual, the agenda's at
21:01:38 <timburke> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:01:51 <timburke> and i even remembered to update it today!
21:02:05 <timburke> first up
21:02:12 <timburke> #topic aws-chunked
21:03:19 <timburke> i think acoles and i have got the chain looking pretty good -- it's time to rally some other people to leave reviews!
21:04:03 <timburke> the chain starts with adding support for the new protocol
21:04:05 <timburke> #link https://review.opendev.org/c/openstack/swift/+/836755
21:04:47 <timburke> then has a series of patches to get us at least validating checksums on upload (even if we aren't storing and returning them yet)
21:05:16 <mattoliver> Kk, I need to loop back to this. If it's ready I'll try to take another look. Might be nice to have a break from the rabbit hole I'm in :)
21:06:13 <timburke> oh, boo! i accidentally left a style error at the end of my last set of uploads. will try to fix that shortly
21:06:43 <timburke> speaking of patches that seem about ready to merge...
21:06:54 <timburke> #topic memcache-tokens to reduce backend requests
21:07:28 <rwmtinkywinky46> o/ (sorry late!)
21:07:33 <timburke> jianjian has been driving this for a while -- i just realized that we've been running with it in prod for more than a year!
21:09:15 <timburke> yesterday i finally got around to really putting it through its paces, and i'm pretty happy with it -- definitely saw a good reduction in backend requests when restarting memcache mid swift-bench run
21:10:26 <timburke> i left a handful of suggestions as potential squash patches, though -- i feel like we can get the code changes a little tighter
21:10:30 <mattoliver> Oh yeah, this is awesome! Made a huge difference, everyone should benefit!
21:11:14 <mattoliver> Kk, so let jian take another look then it might be ready to merge :)
21:11:20 <timburke> after testing, i was left thinking we probably want it on by default :-)
21:12:06 <timburke> all that memcache restarting gave me a little trouble with auth, though, until i remembered...
21:12:15 <timburke> #topic fernet tokens for tempauth
21:12:18 <timburke> #link https://review.opendev.org/c/openstack/swift/+/861271
21:13:11 <timburke> that patch was great! restart memcache, no more trouble with auth!
21:13:31 <timburke> zaitcev already left a +2 -- anyone else want to take a look, or should i just merge it?
21:13:51 <timburke> we've had a similar approach in out out-of-tree auth middleware for some time
21:15:06 <mattoliver> its in tempauth, so feel like its safer to just merge. But I could take a look if you want.
21:15:39 <timburke> either way. it's been around a while
21:16:07 <timburke> next up
21:16:15 <timburke> #topic testing on py313
21:16:58 <timburke> i noticed that py313 is listed as one of the 2025.2 runtimes
21:17:03 <timburke> #link https://governance.openstack.org/tc/reference/runtimes/2025.2.html#python
21:17:21 <timburke> and already merged a unit test job
21:17:28 <timburke> #link https://review.opendev.org/c/openstack/swift/+/947968
21:18:11 <timburke> func tests also already pass
21:18:13 <timburke> #link https://review.opendev.org/c/openstack/swift/+/947998
21:18:38 <timburke> but i'm not sure whether we want CI all the way up there yet
21:19:44 <opendevreview> Merged openstack/liberasurecode master: Make check-symbols.sh work on OS X  https://review.opendev.org/c/openstack/liberasurecode/+/929963
21:19:49 <timburke> i haven't gotten around to trying probe tests yet -- certainly, getting them in CI might be tricky
21:20:48 <timburke> and i should note that all of this is with a python build that still has the GIL, rather than a free-threaded build
21:22:02 <timburke> (the py313 jobs used to grab a free-threaded build, but that changed a few months ago)
21:22:04 <timburke> #link https://opendev.org/zuul/zuul-jobs/commit/b95cfa4ad7bd8083d037104310f766074ec73246
21:24:13 <timburke> i wouldn't mind figuring out how to get a free-threaded build in CI again, but i don't think many of our (transitive) dependencies provided free-threaded wheels, so that could be a complication
21:24:58 <mattoliver> well I like the idea of one day using the free-threaded version of python. Might be a way out of the eventlet hole eventually ;)
21:25:45 <timburke> but it'd be especially nice for pyeclib -- that way we can try to get rid of the `PyUnstable_Module_SetGIL(m, Py_MOD_GIL_USED)`
21:26:00 <timburke> speaking of...
21:26:08 <timburke> #topic modernizing pyeclib
21:26:45 <timburke> i'd appreciate some consensus on us dropping some old python versions there
21:26:48 <timburke> #link https://review.opendev.org/c/openstack/pyeclib/+/938098
21:28:00 <timburke> we currently test on py27, py35, py36, py37, py38, py39, py310, py311, py312, and py313. that's a lot of pythons!
21:29:05 <timburke> from the ptg it sounded like we're ok with dropping more than half of them, to bring pyeclib (at least) in line the broader openstack expectations around supported python versions
21:30:39 <timburke> but it still seems like the sort of change that should merge with more than just my say-so -- so i'd appreciate other cores weighing in on it (if only on the broader "which pythons should we support?" question, rather than the specific tactics of the patch)
21:30:41 <mattoliver> fyi, just checked the tempauth fernet token patch.. looks great! So +Aed it.
21:30:52 <timburke> thanks, mattoliver!
21:31:35 <mattoliver> yes, let's drop the older python releases!
21:31:47 <mattoliver> lets make the testing metric smaller
21:31:53 <mattoliver> *matrix
21:32:35 <timburke> once we do that, we can clean up a bunch of things, too -- not just getting rid of py2-isms (of which there were remarkably few, as i recall), but also using stdlib's enum module
21:33:44 <timburke> and if we *really* want to go all crazy-modern, i even took a stab at moving the project to use pyproject.toml
21:33:48 <timburke> #link https://review.opendev.org/c/openstack/pyeclib/+/947543
21:34:32 <mattoliver> what! pyproject, we're really finally modernizing this stuff :)
21:34:45 <timburke> it's like whoa
21:35:10 <mattoliver> Lol I had draft comment on 938098, opps
21:35:38 <timburke> i think there's a whole lot of stuff in that setup.py that doesn't need to be there in this day and age
21:36:09 <timburke> no worries -- i know i tend to have a lot of unpublished drafts laying around, too
21:36:32 <mattoliver> interesting, but there still is a setup.py so people who still build on older distros cough cough can still build it. I like that
21:37:34 <timburke> mattoliver, bingo! not only that, but PTI has some specific setup.py invocations it expects
21:37:37 <timburke> #link https://governance.openstack.org/tc/reference/pti/python.html#specific-commands
21:38:24 <timburke> anyway, that's all i've got for this week
21:38:37 <timburke> #topic anything else we should bring up?
21:38:43 <rwmtinkywinky46> if there's time, may I ask some object lock questions? :)
21:38:43 <mattoliver> I'll make sure this still builds in our downstream infrastructure, and if it does that I think it's something we can merge. Might need to think about how we bump the next version. But maybe it doesn't matter that much.
21:39:03 <timburke> thanks mattoliver
21:39:28 <timburke> rwmtinkywinky46, absolutely! whenever i see a less-frequently-seen person, i like to try to leave some extra time :-)
21:39:37 <rwmtinkywinky46> thanks :)
21:40:06 <rwmtinkywinky46> we'll be offering a patch set soon(tm) for adding object lock, consisting of a new middleware and patches to s3api to remove the stubs and wire it to the new middleware when it's loaded
21:40:33 <rwmtinkywinky46> however, I'm unclear on how middleware should do role checks, since governance mode relies on the user having a role
21:40:34 <opendevreview> Merged openstack/liberasurecode master: Mark a bunch of things internal  https://review.opendev.org/c/openstack/liberasurecode/+/929974
21:41:09 <rwmtinkywinky46> I *think* we need to also patch swift's keystoneauth to include a config for the role and pass the existance into the env like other role checks are done, but wanted to check this was the expected practice
21:43:42 <timburke> yeah, that sounds right. generally speaking, the auth middleware(s) should be the place making auth decisions. when it can't do that immediately (for example, because one client request spawns multiple backend requests) it does it via the authorize callback
21:45:24 <rwmtinkywinky46> yes okay, thanks. I'll get them working on that part of object lock as well, then I think we might be good to submit. thanks!
21:45:41 <timburke> cool! i look forward to seeing it!
21:45:58 <mattoliver> And if keystoneauth is going to pass in something, like here is a roles of the user, or what ever you need maybe make sure tempauth (being the test/dev version can do it to.. so we can test the features of the new middleware without keytone setup.
21:46:17 <rwmtinkywinky46> okay, I'll make sure that's included!
21:46:48 <mattoliver> it can be super simple there. like just define the roles in the config for a user and it'll be included or whatever.
21:47:46 <rwmtinkywinky46> thanks all for your time :)
21:47:47 <indianwhocodes> o/
21:49:38 <mattoliver> I've been distracted on other downstream work. So I don't have much to report
21:51:03 <timburke> fwiw, tempauth sometimes lags a little behind keystone on features like with https://github.com/openstack/swift/commit/98a0275a and https://github.com/openstack/swift/commit/cf4f3206
21:51:45 <timburke> (mostly i just wanted to find those to offer as an example of the last time we did this sort of a thing)
21:53:08 <timburke> all right, i think i'll call it for the week then
21:53:19 <timburke> thank you all for coming, and thank you for working on swift!
21:53:45 <timburke> reminder that next week we'll be meeting at 0700 instead of 02100
21:53:50 <timburke> #endmeeting