07:01:20 <mattoliver> #startmeeting swift
07:01:20 <opendevmeet> Meeting started Wed Aug 27 07:01:20 2025 UTC and is due to finish in 60 minutes.  The chair is mattoliver. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:01:20 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
07:01:20 <opendevmeet> The meeting name has been set to 'swift'
07:01:32 <mattoliver> Whose here for the swift meeting?
07:01:37 <cschwede> o/
07:02:19 <mattoliver> As always the agenda is at:
07:02:27 <mattoliver> #link https://wiki.openstack.org/wiki/Meetings/Swift
07:02:51 <mattoliver> hey cschwede o/
07:03:03 <mattoliver> let's get started then :)
07:03:18 <mattoliver> #topic Bug triage
07:03:30 <mattoliver> I was suppose to remove this from the agenda
07:03:34 <mattoliver> but forgot..
07:04:07 <mattoliver> I think this is basically on all of us now to help cschwede dig in.. so might leave it off the agenda in the future and we can swing back to it later
07:04:31 <cschwede> Sounds good. Unfortunately nothing new on this one from me this time
07:05:08 <mattoliver> no probs. I wasn't expecting any since the discussion last meeting, just thought I'd bring it up as a topic because I forgot to remove it :P
07:05:15 <mattoliver> let's move on!
07:05:24 <mattoliver> #topic eventlet removal POC update
07:05:52 <cschwede> I made some progress here, and looking forward to discuss this soon with a couple of folks :)
07:06:39 <mattoliver> Nice! yeah talking with timburke earlier this week, we're keen to talk and support as much as we can.
07:07:25 <mattoliver> I look forward to hearing some progress. if not soon then at the vPTG (perfect segway) :P
07:07:43 <mattoliver> #topic October vPTG
07:08:15 <mattoliver> Just a reminder it's on. timburke said he'd get an etherpad ready.
07:08:44 <mattoliver> it'll be Oct 27 - 31
07:08:55 <mattoliver> #link https://ptg.openinfra.org/
07:09:37 <mattoliver> I've been working on builing on top of ringv2 which I'm interested in talking about
07:10:23 <mattoliver> Clays digging into some timestamp collisions that we've been finding.. so all good topics, and if more come about them soon maybe a future meeting topic too ;)
07:10:59 <mattoliver> Not much to say here about the vptg other then think of ideas and please come and have your say
07:11:11 <cschwede> Timestamp collisions related to the rings?
07:11:11 <mattoliver> #topic bringing back MANIFEST.in
07:11:29 <mattoliver> sorry, no, just in some ec objects
07:12:20 <cschwede> Ah, ok - I was wondering what's going on :)
07:12:49 <mattoliver> very edgecase, but when you have thousands of nodes in a cluster that is stupid busy it can happen, and we want to fix it. Been playing with the probetest clay created abount.. I'll find the link and share it in open discussion.
07:13:05 <mattoliver> * about it
07:13:19 <mattoliver> Anyway MANIFEST.in
07:13:34 <mattoliver> #link https://review.opendev.org/c/openstack/swift/+/950615
07:14:22 <mattoliver> Turns out the most not having the MANIFEST.in file is fine for people building python packages and wheels..
07:14:37 <mattoliver> originally we thought it was 100% of the time, so the file was removed
07:15:21 <mattoliver> turns out those build systems only worked because setuptools knows about the git metadata and could find the s3api schema files in the repo data, so would include it.
07:15:42 <cschwede> Yeah, there is some good technical background on #link https://bugs.launchpad.net/swift/+bug/2120590
07:15:59 <mattoliver> thanks!
07:16:40 <mattoliver> But some build systems (nvidia's downstream one for one) pulls the code from github using the tarball api, this includes the code but not the git metadata.. so we were building packages that didn't have the schema files.
07:17:16 <mattoliver> Long story short seems the MANIFEST.in file IS required, and that linked bug shows it wasn't just us.
07:17:43 <mattoliver> So instead of just changing things in our downstream build env seems better to just land the revert.
07:17:51 <mattoliver> And now we have.
07:18:05 <mattoliver> Sorry if this caused s3api issues for any package maintainers.
07:18:41 <mattoliver> Also please don't ask how long it took me to figure out what the f*$% was happening in our build system :P
07:19:17 <mattoliver> Moving on
07:19:23 <mattoliver> #topic unmaintained branches
07:19:33 <mattoliver> #link https://review.opendev.org/c/openstack/releases/+/958101
07:20:23 <mattoliver> So timburke 's been his amazing self and getting some new stable releases out and showing them some love.. but there are a bunch that are old, broken and he wanted to remove the unmaintained branches.
07:20:31 <mattoliver> There is also an email, let me find the link
07:21:05 <cschwede> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/3CJPUXP5TVI2DMCSHONCDM44BFHCJXIZ/
07:21:11 <cschwede> ^ mattoliver
07:21:15 <mattoliver> oh nice, too fast for me!
07:21:45 <mattoliver> Seems there is a openstack-unmaintained-core group, and they might take on the maintence!
07:22:30 <mattoliver> So let's see what happens there, but thought it was interesting enough to mention, so unmaintained-cores!
07:23:46 <mattoliver> #topic ringv2 next steps
07:24:03 <mattoliver> I aluded to this earlier.
07:24:31 <mattoliver> Now that ringv2 has landed, finally, I've started cleaning up and working on some interesting follow ups.
07:25:12 <mattoliver> There are actually a few threads to follow here. Clay has some follow ups on the ringv2 plumbing itself. But I'm working on using ringv2 to do interesting things
07:25:25 <mattoliver> My chain currently starts:
07:25:33 <mattoliver> #link https://review.opendev.org/c/openstack/swift/+/955263
07:26:44 <mattoliver> Basically the first step is to move the past part tables (history tables) in. So things like the recontructor can make better decisions on if the missing frag is out there on an old handoff and if so,, don't bother going to the effort of rebuilding
07:27:07 <mattoliver> basically an auto handsoff first, which I think will be great
07:27:59 <mattoliver> But having the ability to look back a rebalance or so is nice, but it might also be nice to know when they moved.. in case we want to time limit the checking of old primaries.
07:28:36 <mattoliver> So I then added a patch to move the last_part_moves structure from the builder into the ring
07:29:17 <cschwede> yes, really nice and there are also opportunities to help replicated deployments
07:29:33 <mattoliver> (Because I also have a long term plan to itergrated all builder items into the ring knowing that ringv2 allows us to only load the bits we need, we don't need 2 files anymote).
07:29:37 <mattoliver> +1
07:31:00 <mattoliver> As I add more items I realised that the way Ring and RingData interact is a little annoying. Load up a RingData, copy it's contents locally, throw the RingData away. Then later load it again.
07:31:24 <mattoliver> And as I added more datastructors I needed to add them in both places.
07:32:17 <mattoliver> So I ended up with a refactor and Ring / RingData rework patch, which makes the Ring hold on to the RingData and call into it for the datastructures.
07:32:53 <mattoliver> I've now moved that patch up towards the front of the chain, so the others can get slightly simpler.
07:33:06 <mattoliver> Anyway, if anyone is interested in checking it out. Feel free :)
07:34:28 <mattoliver> There is also a patch to just use decorators to clean up the ringbuilder cli.. which is based on comments in the now merged ringv2 patch. Maybe it doesn't need to be in the chain, but it is :P
07:35:41 <mattoliver> But yes basically I hope that the history tables is a good first step into making our consistency engine smarter or at least make smarter decisions :)
07:35:49 <mattoliver> That's all I got there
07:35:52 <cschwede> +1
07:36:06 <cschwede> Thanks for all the updates mattoliver!
07:36:09 <mattoliver> #topic New ISA-L backend for liberasurecode
07:36:31 <mattoliver> timburke and I landed the patch
07:37:02 <mattoliver> #link https://review.opendev.org/c/openstack/liberasurecode/+/954285
07:37:37 <mattoliver> Couldn't think of a cleaver name, and it isn't a drop in replacement for sa_l_rs_vand so coudln't just replace it
07:37:59 <mattoliver> so it's name has stayed as sa_l_rs_vand_inv
07:39:00 <mattoliver> And is the recommended sa_l_rs_vand variant (if you want to run a vand) as it can handle parities > 5
07:39:43 <mattoliver> That's all I got this week
07:39:49 <cschwede> We might want to update the docs too to make it clear that this is the recommended variant?
07:39:51 <mattoliver> #topic open discussion
07:39:59 <mattoliver> oh yeah
07:40:17 <mattoliver> if is hasn't already, I should go check that.
07:40:29 <mattoliver> and make a note in swift and pyeclib too
07:40:39 <cschwede> That would be great!
07:42:16 <mattoliver> Let me find that probe test link that clay wrote
07:43:25 <mattoliver> #link https://review.opendev.org/c/openstack/swift/+/927327
07:44:31 <mattoliver> Anyway, he's also got some wip patches chained up there as he's playing with options.
07:45:09 <mattoliver> I've been playing with it today, so hope to have some comments and reviews on them soon.
07:45:23 <mattoliver> Anyway, that's all I have this week
07:45:28 <mattoliver> anything else to bring up?
07:46:09 <cschwede> Nothing from my side. Again, thx mattoliver for all the updates!
07:46:34 <mattoliver> nps anytime!
07:46:53 <mattoliver> Then let's end the meeting. Thanks again for coming and thanks for working on swift!
07:46:57 <mattoliver> #endmeeting