21:00:15 <timburke> #startmeeting swift
21:00:15 <opendevmeet> Meeting started Wed Sep 17 21:00:15 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:15 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:15 <opendevmeet> The meeting name has been set to 'swift'
21:00:18 <timburke> who's here for the swift team meeting?
21:00:44 <mattoliver> o/
21:01:44 <timburke> i neglected to update it, but the agenda's usually at
21:01:46 <timburke> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:02:09 <timburke> but i can still come up with an agenda off the top of my head ;-)
21:02:19 <timburke> #topic vPTG
21:02:42 <timburke> it's next month!
21:02:54 <mattoliver> Woo \o/
21:02:55 <timburke> and we ought to get more topics on the etherpad
21:02:58 <timburke> #link https://etherpad.opendev.org/p/swift-ptg-gazpacho
21:03:32 <timburke> #topic release
21:03:43 <mattoliver> Yeah, I haven't added anything yet. Ill n think about some topics to add.
21:03:57 <timburke> swift 2.36.0 is out! and we've got a stable/2025.2 branch now
21:05:17 <timburke> a lot of good stuff in there, including improves s3api support (especially with newer AWS SDKs) and ring v2
21:05:41 <mattoliver> Nice one
21:06:09 <timburke> #topic timestamp collisions
21:06:58 <timburke> i touched on this a little two weeks ago, particularly in the context of ec+encryption leading to data loss (or at least, unavailability pending manual repair 😬)
21:07:25 <timburke> but it's shown up in another context in between!
21:08:24 <timburke> during a part power increase, we started seeing 503s on PUT because linkat doesn't have the same clobbering semantic as rename
21:09:26 <mattoliver> I guess when a cluster gets big and busy enough collisions are more frequent
21:09:42 <mattoliver> At least they always seem to be the same data each time.
21:09:58 <timburke> so we'd have two clients racing to put data with the same name and timestamp, and at the old part we'd see the trouble previously mentioned but then the new part would hit EEXIST for whoever lost the race
21:10:56 <timburke> this in turn led to an UnboundLocalError (!) because of some exception-handling changes in the py2->py3 transition
21:11:13 <timburke> for more info, see
21:11:16 <timburke> #link https://bugs.launchpad.net/swift/+bug/2122543
21:11:36 <timburke> fix is already merged, but that was... interesting... to diagnose
21:13:13 <timburke> meanwhile, clayg is working on getting that EEXIST to pop sooner, which seems like the right call
21:13:15 <timburke> #link https://review.opendev.org/c/openstack/swift/+/961323
21:14:13 <timburke> and i still owe mattoliver a review on trying to sidestep the issue entirely by using offsets in the timestamps
21:14:16 <timburke> #link https://review.opendev.org/c/openstack/swift/+/959009
21:15:20 <mattoliver> yeah, if you get the chance.
21:16:30 <timburke> #topic swiftclient
21:16:54 <timburke> i bumped into an issue that prompted me to write a swiftclient patch
21:17:04 <timburke> only to discover the gate was broken!
21:17:49 <timburke> as best i can tell it was just to do with us pinning to an old version of tox during that 3->4 transition
21:17:55 <timburke> so i just removed the pin
21:17:57 <timburke> #link https://review.opendev.org/c/openstack/python-swiftclient/+/961430
21:19:01 <mattoliver> oh, nice find. Not that finding the gate broken is good, but glad you figured out why
21:19:38 <timburke> if you're curious about what led me there, the authv1 plugin i cobbled together stopped working for some operations because it was returning an old v2-style service catalog, so i wanted to update it to v3-style
21:19:49 <timburke> #link https://review.opendev.org/c/openstack/python-swiftclient/+/961423
21:20:12 <timburke> though it looks like i need to fix a pep8 issue in my new tests
21:21:27 <timburke> #topic eventlet removal
21:22:35 <timburke> i haven't taken a look for a bit, but i'm inclined to keep the feature branch moving, so i think i'll merge the first patch or two (after taking off the WIP from the commit message)
21:23:45 <timburke> maybe i'll even get to the point of running with gunicorn account servers locally :-)
21:24:18 <timburke> i think that's all i've got by way of topics
21:24:22 <timburke> #topic open discussion
21:24:30 <timburke> anything else we ought to bring up this week?
21:24:40 <mattoliver> yeah, I've been meaning to give it a whirl too. But just haven't had time.
21:25:27 <mattoliver> Also I think it's fine to land older patches after some predetermined time on a feature branch when it makes sense to keep things going. only needs to be open long enough for people to comment
21:25:52 <timburke> +1
21:26:43 <mattoliver> On the open discussion side of things, I've been playing with past_part_node in the reconstructor again.
21:26:51 <timburke> nice!
21:26:53 <mattoliver> Basically rebased and cleaned up the old patch
21:26:59 <mattoliver> #link https://review.opendev.org/c/openstack/swift/+/835001
21:28:08 <mattoliver> still needs more work. I've tried adding a time check going back and calling REVERT on an old primary if it moved too long ago via the new last_parts_moved now in the ring (in that chain)
21:28:48 <mattoliver> But it's still a WIP. Need to update and write a whole bunch of new tests now that it looks into last_part_moves.
21:29:35 <mattoliver> but progress.
21:30:11 <mattoliver> last_part_moves still only has a grainulatrity of hours.. so that feels a little wierd
21:31:14 <timburke> idk -- hours doesn't seem bad to me. how long do our reconstructors take to do a cycle these days?
21:32:39 <timburke> and at the other end, capping out at 255 hours gives us more than ten days' history
21:34:00 <mattoliver> true, just in most things, when we let there be a timeout its in seconds. Maybe I just need to not make it an option for people.. and come up with some constant (the full 10 days) or something else auto.
21:34:33 <mattoliver> anyway, just playing with it. and will tidy up the implementation
21:35:04 <timburke> i suppose i ought to look at the patch, see how the impedance mismatch works out
21:36:40 <mattoliver> I'd appreciate that, but I know there are alot going on :) Just trying to push it forward :)
21:37:17 <mattoliver> That's all I've got
21:37:39 <timburke> all right, maybe i'll end it early
21:37:49 <timburke> thank you for coming, and thank you for working on swift!
21:37:53 <timburke> #endmeeting