Wednesday, 2026-01-21

opendevreviewASHWIN A NAIR proposed openstack/swift master: s3api: fix s3api mpu complete log for correct c/o  https://review.opendev.org/c/openstack/swift/+/96691700:12
opendevreviewAlistair Coles proposed openstack/swift master: timestamps: add SimpleTimestamp for ShardRanges  https://review.opendev.org/c/openstack/swift/+/96874010:11
opendevreviewAlistair Coles proposed openstack/swift master: WIP Timestamp: add random jitter to offset field  https://review.opendev.org/c/openstack/swift/+/96773810:11
opendevreviewAlistair Coles proposed openstack/swift master: object_server: return 400 if POST timestamp has jitter  https://review.opendev.org/c/openstack/swift/+/97253510:11
opendevreviewAlistair Coles proposed openstack/swift master: tolerate but round meta timestamp jitter in backend  https://review.opendev.org/c/openstack/swift/+/97253610:11
opendevreviewAlistair Coles proposed openstack/swift master: Fix flakey proxy server test_node_timing  https://review.opendev.org/c/openstack/swift/+/97421517:03
timburkealmost swift meeting time!20:55
acoles<drum roll>20:58
mattoliverOh swift meeting?21:04
timburke#startmeeting swift21:07
opendevmeetMeeting started Wed Jan 21 21:07:09 2026 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.21:07
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.21:07
opendevmeetThe meeting name has been set to 'swift'21:07
timburkeheh, sorry -- got distracted21:07
timburkehello again!21:07
mattoliverlol, nps, i have a very bad track record :P 21:07
timburkewho's here for the swift team meeting?21:07
mattolivergreat to see ya tim!21:07
mattolivero/21:07
acoles\o21:08
timburkeas usual, the agenda's at21:08
timburke#link https://wiki.openstack.org/wiki/Meetings/Swift21:08
timburkefirst up21:08
timburke#topic health update21:08
timburkehi! been a while since i led a meeting -- i've been busy dealing with health issues21:09
timburkethe good news is that things seem to be leveling out a bit, so i hope to be more involved and keeping up with things better21:09
acolesgood to hear that timburke 21:10
mattoliverwell thats good to hear! We've realy missed you21:10
timburkebig thanks to everyone (especially mattoliver) for keeping things going without me21:10
timburkei suppose it's still a bit of an open question of whether i should nominate myself for PTL next cycle... i guess we'll see how things are next month21:11
mattoliverbarely, but doing what I could, big shoes to fill. 21:11
timburke'cause i do feel a bit bad about leaving things in the lurch21:11
mattoliverlets take it a week ata time. 21:11
mattoliverno, don't you worry about that 21:12
timburke👍21:12
acoleswe can cope with a lurch, do what's right for you21:12
timburkenext up21:12
timburke#topic keystone security bug21:12
timburkei didn't see that this had been covered in the last few meetings, so i wanted to make sure it got called out now21:12
timburkethere was a security bug in the way that swift and keystone communicate about s3api access. for more info see21:13
timburke#link https://bugs.launchpad.net/keystone/+bug/211964621:13
patch-botBug #2119646 - [OSSA-2025-002] Unauthenticated access to EC2/S3 token endpoints can grant Keystone authorization (CVE-2025-65073) (Fix Released)21:13
timburkethe long and short of it is that keystone now requires auth tokens be sent by the s3api middleware, which we never did before21:14
timburkegood news is that all the relevant patches are merged now (most/all of them merged back in november)21:15
mattoliver\o/21:15
timburkeand that includes backports to stable branches and even unmaintained/2024.121:16
timburkebad news is that we still haven't tagged any releases for any of that -- so i ought to get on it21:16
mattoliverahh nice segway21:17
timburkefor any operators that rely on s3api for keystone users, note that you'll want to upgrade (and properly configure) swift first *then* keystone, to minimize downtime for your users21:18
timburkebut yeah, next up21:18
timburke#topic swift release21:18
timburkei put up an authors/changelog patch for swift 2.37.021:18
timburke#link https://review.opendev.org/c/openstack/swift/+/97281221:19
patch-botpatch 972812 - swift - AUTHORS/CHANGELOG for 2.37.0 - 6 patch sets21:19
timburkethanks for taking a look at it already mattoliver21:19
timburkeit was probably one of the harder changelogs to put together -- mostly just because i've been so out of the loop. so if you get a chance, please take a look and let me know if there's anything i should have mentioned but didn't21:20
acolesdo you need another review?21:20
timburkecouldn't hurt, if you don't mind21:20
acolesoh, ok, I'll take a look :)21:20
timburkei still need to rebase and reno-ize it, anyway, so there's going to be at least one more patchset :-)21:21
timburkebut i hope to get that merged/released in the next week or so (of course, that's what i said last week, too...)21:21
timburkefrom there, i'll start doing stable releases, but that should be easier/faster21:22
timburkeand then there was *one* thing i was still hoping to fix before the release...21:22
timburke#topic docker image uploads21:23
timburkethey're broken!21:23
timburkehave been since opendev needed to re-key the world -- for more info, see21:23
timburke#link https://lists.opendev.org/archives/list/service-announce@lists.opendev.org/thread/WBBLBI6ZS6FA6Q5ZMH4C2MWPL3WG3H24/21:23
mattoliverahh ok that explains why it broke21:24
timburkemattoliver has already rotated the password, so now we just need to update the secret in our .zuul.yaml21:24
timburke...which has proven more difficult that expected21:24
timburkethat was complicated by the fact that the only way to verify that i did the update right seems to be attempting to merge this fix (to a non-voting job!)21:26
mattoliverand we should document the procedure once we get it working, so future us aren't pulling our hair again :P 21:26
timburkehence p 973194 merging but leaving the job busted21:27
patch-bothttps://review.opendev.org/c/openstack/swift/+/973194 - swift - Update dockerhub secret (MERGED) - 3 patch sets21:27
timburkebut (1) it's busted in a new way -- POST_FAILURE instead of RETRY_LIMIT and (2) i eventually figured out that we want to merge it as a fix for a *voting* job, then fast-follow with another patch to put it back to non-voting21:28
timburke#link https://review.opendev.org/c/openstack/swift/+/97399021:28
patch-botpatch 973990 - swift - CI: Update dockerhub secret (again) - 1 patch set21:28
timburke#link https://review.opendev.org/c/openstack/swift/+/97399121:28
patch-botpatch 973991 - swift - CI: Make swift-upload-image non-voting again - 1 patch set21:28
mattoliverwhat21:29
timburkei'll keep poking at it, probably reach out to folks in openstack-infra or openstack-dev21:30
mattoliverthat seems nuts21:30
mattoliverlol, tanks for taking it on!21:30
timburkeseems like the secret's getting decrypted now (yay!), but login fails -- which is weird because the same commands seem to work OMM21:30
timburkelike i said, i'll keep poking at it. but i suppose it shouldn't really be a release blocker21:31
timburkenext up21:31
timburke#topic timestamp collisions21:31
timburkei know acoles and mattoliver have been working on this a good bit lately -- take it away!21:32
acolesfirst we made a bit of progress understanding why we see these collisions21:32
acoles]mostly thanks to Clay...21:32
acoleswe think we have a client request stalled in a proxy accept queue for long enough that the client retries. Then the retry and the original enter the proxy concurrently and by chance get the same timestamp. That's a hypothesis at least, can't prove it.21:33
acolesOnto the fix...21:33
timburkeis the hypothesis that these requests go to the same proxy, or different proxies?21:34
acolesthe plan is to add some random 'jitter' into the existing extra hex part of the timestamp, to effectively increase the precision of the 'time'.21:34
mattoliverdifferent proxies21:35
timburke👍21:35
jianjianto different proxies from what I can tell, but could be same proxy in theory21:35
acolesWe've needed to do a lot of work to cleanup timestamp handling in tests to allow for them now always (almost always) having the offset part21:35
acolessomething like 40 patches merged in this quest.21:36
acolesthere's  a few more preparatory patches to reduce the places where we assign the x-timestamp, which gets us ready to...21:36
acolesadd jitter to request timestamp, initially only for object PUT which is where we see the problem (one step at a time rather than all request types in a big bang)21:37
acolesthe patch chain leads to here https://review.opendev.org/c/openstack/swift/+/967738 (and coninues with some follow ons)21:38
patch-botpatch 967738 - swift - WIP Timestamp: add random jitter to offset field - 48 patch sets21:38
mattoliverI'll take a look at the new preparatory patches21:38
acolesI'd love to get al the prep patches out of the way so that we can start to haggle over the implementation details of the timestamp change21:38
acolesthanks mattoliver 21:39
acolesI hope that all the cleanup will prove to be a good step forwards regardless.21:40
timburkei'll take a look, too -- been trying to approve as many of those pre-reqs as i could ;-)21:40
mattoliveryeah, just makes sense to use timestamp classes anyway, its swifts way of dealing with time. 21:40
timburkeall right, last up (from me, anyway)21:41
timburke#topic LRC scheme for liberasurecode21:41
timburkethis has been brewing for a while -- someone at OVH wants to add locally repairable (or recoverable, depending on the literature you're following) codes21:42
timburkethis lets you have a scheme like 8+4, but where some (say, 2) of those parities are "global" and some (the other 2) are "local"21:43
mattoliverok, interesting21:44
acoleswhat's the significance of local/global?21:45
timburkeso if you've got two regions, you send 4 data frags and one local parity to each region, then you don't need any cross-region traffic to rebuild so long as you've still got 4 of those 5 frags21:45
mattoliversounds like I have some reading to do21:45
timburkewhereas you'd normally need *8* frags to do any reconstruction at all21:45
acolesare all the frags the same size?21:46
timburkeyup21:46
acolesbut bigger then a regular 8+4 scheme??21:47
jianjianwhat if operator wants to use 8+3 or 10+5?21:47
timburkedownside is that you can no longer take an arbitrary set of 8 frags and be assured you can decode -- if you get 4 data frags from one region, the local parity frag for that region is redundant21:48
timburkejianjian, any scheme should be supported; basically there's a one more parameter to it: instead of just k (ndata) and m (nparity), there's also an l (nregions? must be <=m)21:49
timburketrying to get this to be something useful *in swift* is probably still a ways off -- but the liberasurecode patch seems to be getting somewhat close21:50
timburke#link https://review.opendev.org/c/openstack/liberasurecode/+/95928021:50
patch-botpatch 959280 - liberasurecode - feature: LRC (locally repairable code backend) - 15 patch sets21:50
jianjianoh, got it21:50
timburkeif you're interested in erasure coding, linear algebra, or reducing the connections needed for reconstruction, consider taking a look!21:51
timburkethere have also been a handful of patches kicked out to liberasurecode and pyeclib as i dug into this -- thanks for taking a look at some of them, mattoliver!21:52
timburkeall right, i think that's all i've got21:52
timburke#topic open discussion21:52
timburkeanything else we should bring up this week?21:52
mattoliverI've got nothing else to bring up21:53
acolesnor me21:53
timburkeall right, let's call it then21:55
timburkethank you all for coming, and thank you for working on swift!21:55
timburke#endmeeting21:55
opendevmeetMeeting ended Wed Jan 21 21:55:47 2026 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:55
opendevmeetMinutes:        https://meetings.opendev.org/meetings/swift/2026/swift.2026-01-21-21.07.html21:55
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/swift/2026/swift.2026-01-21-21.07.txt21:55
opendevmeetLog:            https://meetings.opendev.org/meetings/swift/2026/swift.2026-01-21-21.07.log.html21:55
jianjianbye~21:55
mattoliverthanks timburke !21:57
opendevreviewMerged openstack/swift master: Fix flakey proxy server test_node_timing  https://review.opendev.org/c/openstack/swift/+/97421521:58

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!