21:02:56 <timburke> #startmeeting swift
21:02:56 <opendevmeet> Meeting started Wed Jul  9 21:02:56 2025 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:56 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:56 <opendevmeet> The meeting name has been set to 'swift'
21:03:03 <timburke> who's here for the swift meeting?
21:03:04 <zaitcev> o/
21:03:34 <zaitcev> Looks like it's going to be a short one.
21:04:11 <timburke> sorry for missing the last couple meetings i was supposed to host
21:04:29 <timburke> but i'm here this week! may as well get into it
21:04:38 <timburke> as usual, the agenda's at
21:04:40 <timburke> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:04:48 <timburke> first up
21:04:56 <timburke> #topic DCO replaces CLA
21:06:42 <timburke> i know mattoliver brought this up last week, but in case anyone missed it: we've moved from having everyone sign a contributor license agreement before they can upload patches to requiring that every patch uploaded includes a sign-off for the developer certificate of origin
21:07:37 <timburke> this was brought up on the mailing list back in may
21:07:39 <timburke> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/A7S24NMKOQZFXRAAEEYQX23S6UF4WML2/
21:08:09 <timburke> but only fairly recently started having the gerrit hooks enforce the sign-off
21:08:15 <timburke> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/KGEKDH3AKRM3CKQW7SEVVVQFV2X6OCF6/
21:08:50 <timburke> for more information (including the text of the dco), see
21:08:52 <timburke> #link https://docs.openstack.org/contributors/common/dco.html
21:10:04 <timburke> tl;dr: expect to need to add `-s` to your commits and rebases
21:10:12 <timburke> next up
21:10:22 <timburke> #topic October vPTG
21:10:47 <timburke> dates are set for 10/27-10/31
21:11:11 <timburke> register at
21:11:12 <timburke> #link https://ptg.openinfra.org/
21:11:33 <zaitcev> Dunno if I can but I'll take a look.
21:11:40 <timburke> i'll work on getting an etherpad and schedule worked out, but we've got some time still
21:13:07 <timburke> i'm pretty sure i already responded to express the swift team's interest in participating
21:14:10 <timburke> one more fyi
21:14:17 <timburke> #topic 2026.1 codename
21:14:31 <timburke> it's gazpacho
21:14:34 <timburke> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/QVZK5PFN233WNDX764B2NZ4W65U27FF4/
21:15:18 <timburke> (if i'd noticed the poll in time, i would've voted for gazelle, but that's me)
21:15:48 <timburke> next up
21:15:58 <timburke> #topic new liberasurecode backend
21:16:15 <timburke> this one came out of left-field for me this week
21:17:15 <timburke> someone apparently has an interest in using proper vandermonde encoding/decoding, such that we avoid the nparity<=4 requirement
21:17:32 <timburke> #link https://review.opendev.org/c/openstack/liberasurecode/+/954285
21:18:57 <timburke> as best i can tell, we ought to be able to do something very similar to what we did for the rs_vand/rs_cauchy split -- just change the way we generate the EC encoding matrix, then let isa-l do its normal thing from there
21:20:32 <timburke> note that the patch is not in shape to merge yet -- currently it replaces the encoding matrix entirely (for both isa_l_rs_vand *and* isa_l_rs_cauchy!), with no option to use the old one
21:21:49 <zaitcev> But isn't it a perfect superset? So it's only a question of safety, right?
21:22:13 <timburke> ...which would mean that no currently-existing parity fragments would be good anymore
21:22:25 <zaitcev> Oh
21:23:02 <timburke> but i think i could see a way to get it to something useful -- we just need to define it as a whole new backend (again, rather like we did when we introduced rs_cauchy)
21:23:57 <timburke> fwiw, the matrix generation seems to match what other projects do
21:23:59 <timburke> for example, https://github.com/tahoe-lafs/zfec/blob/zfec-1.6.0.0/zfec/fec.c#L430-L479
21:24:24 <timburke> also, the description at https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction#Systematic_encoding_procedure:_The_message_as_an_initial_sequence_of_values
21:26:06 <timburke> i think the biggest question i've got left is what we'd want to call the thing -- once i've got that, i might go offer some follow-up patch to get things more in the shape i'd expect
21:26:29 <timburke> isa_l_rs_vand_inv, maybe? isa_l_rs_vand2?
21:28:12 <zaitcev> Does not matter to me tbh.
21:29:25 <timburke> alright, last item
21:29:44 <timburke> #topic dsvm devstack gate breakage
21:30:22 <timburke> more of an fyi since it's resolved now, but still
21:31:13 <timburke> while i was trying to get better s3api func test coverage, i had us start running the s3 cross-compat tests as part of the dsvm job
21:31:25 <timburke> #link https://github.com/openstack/swift/commit/38ad3a4
21:31:51 <timburke> unfortunately, that broke devstack's gate
21:32:30 <timburke> (i think at some point i knew our job was included for their repo, but i'd forgotten)
21:33:14 <timburke> the reason was somewhat sneaky, or maybe it's just that i'm not super-familiar with zuul and cross-project testing
21:34:37 <timburke> to make our dvsm job test both keystone and tempauth, we configure two test.conf files -- /etc/swift/test.conf (for keystone users) and we update test/sample.conf (for tempauth)
21:35:19 <timburke> but the way our roles found the tempauth file was {{ ansible_env.HOME }}/{{ zuul.project.src_dir }}/test/sample.conf
21:36:05 <zaitcev> Still not seeing why that was bad.
21:36:28 <zaitcev> I see you added ../swift
21:36:34 <timburke> which works great for our repo, but means we add test/sample.conf files to other repos when they include our job
21:37:14 <timburke> ...which then gets ignored, because the test-running job just says "test/sample.conf" while CWD is the swift repo dir
21:38:29 <timburke> but yeah, the solution was to bump back out of the project repo and make sure we go updating the file in the swift repo (ie, the one that will be used when running tests)
21:38:39 <timburke> #link https://github.com/openstack/swift/commit/e9da48da
21:38:40 <jianjian> thanks Tim for enabling s3 cross-compat tests as part of the dsvm job
21:39:29 <jianjian> I wonder if we can also run those tests twice, once for us, once against real s3 😉
21:40:16 <jianjian> in case some future s3 updates break our cross-compat tests silently
21:40:39 <timburke> jianjian, potentially -- i know we can get secrets into .zuul.yaml (we use it to publish to dockerhub), but i forget how. alternatively, we could set up some 3rd party CI for it
21:41:21 <timburke> anyway, that's all i've got
21:41:25 <timburke> #topic open discussion
21:41:32 <timburke> anything else we should bring up?
21:43:18 <jianjian> not from me
21:43:24 <timburke> the cross-compat trouble reminds me i should push a little more on some other improvements there -- we don't actually run with keystone users when we think we do :-/
21:43:26 <timburke> #link https://review.opendev.org/c/openstack/swift/+/951339
21:44:49 <timburke> and i still want to make sure that we call `check_signature` when caching secrets (so keystone users can rely on aws-chunked transfers working)
21:44:52 <timburke> #link https://review.opendev.org/c/openstack/swift/+/949671
21:46:35 <timburke> as a heads-up, i'll be on vacation all next week -- though mattoliver will be running the 0700 meeting anyway
21:46:47 <jianjian> I think 951339 needs review, I will try to understand those yaml files
21:47:31 <jianjian> summer is here, have fun!
21:48:43 <timburke> thanks -- let me know if you'd like a primer on (my imperfect understanding of) how the zuul stuff works
21:49:26 <timburke> all right, i'll call it for this week
21:49:37 <timburke> thank you all for coming, and thank you for working on swift!
21:49:40 <timburke> #endmeeting