21:02:56 <timburke> #startmeeting swift
21:02:56 <opendevmeet> Meeting started Wed Feb 28 21:02:56 2024 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:05 <timburke> who's here for the swift meeting?
21:03:14 <mattoliver> o/
21:03:24 <kota> o/
21:04:33 <mattoliver> I might have to duck outside at some point as someone is coming to borrow a honey extractor, and they may come during this meeting. Just a heads up :)
21:05:39 <timburke> no worries :-)
21:05:43 <timburke> first up
21:05:50 <timburke> #topic swiftclient release
21:06:07 <timburke> thanks for reviewing some swiftclient patches recently mattoliver!
21:06:26 <timburke> we've got a release request up now for a 4.5.0
21:06:36 <mattoliver> nps, and nice!
21:06:41 <timburke> #link https://review.opendev.org/c/openstack/releases/+/910210
21:06:41 <patch-bot> patch 910210 - releases - Release final python-swiftclient for 2024.1 Caracal - 2 patch sets
21:07:05 <mattoliver> My bad fir not getting to it sooner as there are other patches that could have been good in the release.. but still have we have is better then it was before :)
21:07:27 <mattoliver> *what we have is better then it was before
21:07:40 <timburke> it doesn't include the transaction id or formpost subcommand, but that just ensures we'll have some notes to 4.6.0, right? ;-)
21:07:55 <mattoliver> lol, good point ;)
21:11:25 <timburke> kind of related to releases...
21:11:32 <timburke> #topic unmaintained branches
21:12:00 <timburke> there's also a proposal to move victoria through xena branches to unmaintained status
21:12:07 <timburke> #link https://review.opendev.org/c/openstack/releases/+/910418
21:12:07 <patch-bot> patch 910418 - releases - [swift] Transition EM branches to Unmaintained - 1 patch set
21:13:05 <timburke> there was a similar thing for yoga -- and it wound up involving some weird/annoying churn around release notes
21:13:38 <mattoliver> sounds good to me, seeing as we at nvidia use master :P but would be nice to hear from redhat, as they're the ones who do the long extended maintence thing
21:13:47 <timburke> so i might push for EOLing at least the client branches sooner rather than later
21:13:59 <mattoliver> sounds like a good start
21:14:14 <timburke> since client in particular so rarely gets stable patches
21:15:50 <timburke> next up...
21:15:55 <timburke> #topic py312
21:16:11 <timburke> most all the py312 patches have landed now!
21:16:32 <timburke> iirc, tests should all pass now
21:16:42 <kota> excellent
21:16:50 <timburke> well, all *swift* tests
21:17:02 <timburke> #link https://review.opendev.org/c/openstack/pyeclib/+/839643
21:17:02 <patch-bot> patch 839643 - pyeclib - Drop support for liberasurecode<1.4.0 - 10 patch sets
21:17:59 <timburke> pyeclib has a lingering use of pkg_resources, which isn't so readily available in py312
21:18:49 <timburke> it was only being used to check the libec version, though -- so if we drop support for ancient libec, we get the pkg_resource cleanup "for free"
21:19:05 <mattoliver> oh cool
21:19:27 <timburke> that patch would also (finally!) put to bed
21:19:29 <timburke> #link https://bugs.launchpad.net/swift/+bug/1639691
21:19:30 <patch-bot> Bug #1639691 - EC: Swift can return corrupted Data and be able to go data lost at isa_l_rs_vand policy with >=5 parities (Fix Released)
21:19:40 <mattoliver> oh double awesome!
21:19:49 <mattoliver> kk, I'll put it on my list to review
21:20:26 <kota> that's much old one.
21:21:27 <timburke> thanks. i can look at getting a pyeclib release together, too. i might wait until after the caracal cycle wraps, though, just to avoid some confusion
21:22:57 <timburke> and if i'm doing that, i might freshen up p 817498 too :D
21:22:57 <patch-bot> https://review.opendev.org/c/openstack/pyeclib/+/817498 - pyeclib - Add Dockerfile to build manylinux wheels - 9 patch sets
21:23:35 <timburke> it'd be *real* fancy if i could figure out how to get binary wheels published to pypi!
21:24:10 <mattoliver> oh yeah :hmm:
21:24:39 <timburke> i've been using them to great effect at home ;-) to the point that i often lean on my home wheels for various dev environments, too
21:27:29 <timburke> oh! there was one more python-next patch i wanted to call out -- it's still just causing deprecation warnings on py312, but will cause failures on py313
21:27:37 <timburke> #link https://review.opendev.org/c/openstack/swift/+/887908
21:27:38 <patch-bot> patch 887908 - swift - Stop using cgi.parse_header - 3 patch sets
21:28:19 <timburke> mattoliver took a look recently! (thanks!) it's still on me to follow-up
21:29:22 <mattoliver> yup and when you do, I'll be ready to look again :)
21:29:32 <mattoliver> or I could just double check things :P
21:29:36 <mattoliver> *myself
21:30:40 <timburke> i think there's a fair question of how much to fully support every possible variation of header params vs only as much as we seem to use ourselves
21:31:24 <timburke> but i should take a closer look at which headers actually need this kind of parsing
21:32:01 <timburke> next up
21:32:11 <timburke> #topic expirer delay
21:32:52 <timburke> there's been some good progress on the various expirer patches, and now we even have some docs patches!
21:33:13 <timburke> #link https://review.opendev.org/c/openstack/swift/+/874806
21:33:14 <patch-bot> patch 874806 - swift - Add per account grace period to object expirer - 10 patch sets
21:33:27 <timburke> #link https://review.opendev.org/c/openstack/swift/+/907762
21:33:28 <patch-bot> patch 907762 - swift - expirer: add per-container grace period - 8 patch sets
21:33:38 <timburke> #link https://review.opendev.org/c/openstack/swift/+/909928
21:33:39 <patch-bot> patch 909928 - swift - add documentation for grace period - 5 patch sets
21:34:11 <timburke> #link https://review.opendev.org/c/openstack/swift/+/874710
21:34:11 <patch-bot> patch 874710 - swift - Add x-open-expired to recover expired objects - 27 patch sets
21:34:21 <timburke> #link https://review.opendev.org/c/openstack/swift/+/907774
21:34:21 <patch-bot> patch 907774 - swift - add enable open expired in proxy config - 13 patch sets
21:34:30 <timburke> #link https://review.opendev.org/c/openstack/swift/+/910286
21:34:31 <patch-bot> patch 910286 - swift - add documentation for accessing expired objects - 3 patch sets
21:36:47 <timburke> we might still want to squash some of those together (the last three, in particular, i think i'd rather see all as one patch), but i think they'll be able to land soon-ish
21:38:02 <timburke> :-( i see at least one of those patches failed tests because of https://bugs.launchpad.net/swift/+bug/2028175
21:38:03 <patch-bot> Bug #2028175 - intermittent probe test failure: test_reconciler_move_object_twice (New)
21:38:56 <mattoliver> oh a ton of work
21:38:57 <timburke> and thinking about it more, i think it might hint at a general reconciler bug
21:42:01 <mattoliver> yeah, and its a probe test, so at least something to dig into
21:42:21 <timburke> basically: when we first see that an object in policy A should be in policy B, we create a job to move us from "object in A at time t0" to "tombstone in A at time t0_1 and object in B at time t0_2", right?
21:43:22 <timburke> so when we later find out that it should *really* be in policy C... the proper, settled state depends on whether the reconciler was previously settled or not!
21:44:38 <timburke> you could *either* end up with "B@t0_2 -> C@t0_4" *or* "A@t0 -> C@t0_2" units of work
21:45:12 <mattoliver> oh right.
21:45:35 <mattoliver> I would think that t0_2 would win, but I guess spit brain
21:45:37 <timburke> unfortunately, i don't have a good clean way to fix it in mind (yet)
21:46:38 <timburke> but we should probably think about it some more (especially if we want to have any hope of cluster-assisted policy migration)
21:46:49 <mattoliver> +1
21:47:23 <timburke> all right, i think that's all i really wanted to bring up
21:47:28 <timburke> #topic open discussion
21:47:34 <timburke> anything else we should talk about?
21:48:23 <mattoliver> I haven't really pushed any of my patches forward this week so probably not much to say.
21:49:20 <mattoliver> So yeah I'm good. Expecting someone to turn up at anytime anyway :)
21:49:21 <timburke> you pushed on https://review.opendev.org/c/openstack/python-swiftclient/+/833954 ! i'll take another look
21:49:21 <patch-bot> patch 833954 - python-swiftclient - Add formpost subcommand to generate signature - 8 patch sets
21:49:29 <mattoliver> oh yeah I did that
21:49:41 <mattoliver> reworked it to look a little more like swiftclient's tempurl
21:49:59 <mattoliver> including using all the existing time stuff (because that at least makes sense)
21:50:23 <mattoliver> although it doesn't allow normal UTC times as the expires query param
21:50:29 <timburke> nice! i was thinking i'd like to see that as a follow-up if nothing else :-)
21:51:09 <mattoliver> originally I wanted to keep it just like it was in swiftclient so it wouldn't be confusing..
21:51:42 <mattoliver> but then realised people using swiftclient would expect it to be more familar to swiftclient rather then swift :)
21:51:59 <mattoliver> sorry, originally keep it like it was in swift
21:52:03 <timburke> still, if the user can specify a more readable timestamp, that's a definite win even if we're ensuring it's expressed as seconds-since-epoch
21:52:15 <mattoliver> +1
21:53:14 <mattoliver> also the code was there in a helper method, so stupid not to use it :P
21:53:50 <timburke> oh! something i probably won't act on just yet, but good to keep in mind: acoles expressed an interest in a new feature branch! give us somewhere that we could all collaborate on a new swift-native MPU implementation
21:54:06 <zaitcev> python -c 'import time; print(time.time())'
21:54:36 <zaitcev> swift-native what implementation?
21:54:55 <mattoliver> oh we haven't needed one of those in a while. All the work Al has been putting into planning, yeah he has big plans and I might be warrented
21:54:56 <timburke> multi-part upload -- sorry, S3-ism
21:55:35 <mattoliver> zaitcev: I meant the formpost signature generation.
21:55:37 <zaitcev> I dimly recall we talked about something like a new and improved SLO
21:56:08 <timburke> yup! now that acoles is on it, it's way more likely to get to completion ;-)
21:56:32 <timburke> i think https://bugs.launchpad.net/swift/+bug/1813202 is probably the most glaring reason we want something better than SLO -- there'll almost certainly be a new async-cleanup daemon involved
21:56:32 <patch-bot> Bug #1813202 - s3api does not clean up orphan segment parts when MPU is overwritten (Confirmed)
21:56:52 <mattoliver> there was a tool in swift to generate it. And have moved it to swiftclient (list we did for tempurl) and tempurl allows you to pass in seconds, or use abreviations or even provide and absolute UTC time when providing the expiry.
21:56:56 <timburke> https://review.opendev.org/c/openstack/swift/+/800701 touches on some motivation, too, though
21:56:57 <patch-bot> patch 800701 - swift - Delete s3api MPU segments when the manifest expires - 32 patch sets
21:58:26 <timburke> conversely, we've *also* seen users unwittingly delete their segments then be confused as to why the large object stopped working...
21:59:50 <timburke> i think it probably makes the most sense to hold off on creating the branch until we've got a starting point to hack on, but i'm excited to have something we think has enough scope and interest to warrant a feature branch again :-)
22:00:03 <mattoliver> +100
22:00:36 <timburke> all right, we're at time
22:00:46 <timburke> thank you all for coming, and thank you for working on swift!
22:00:51 <timburke> #endmeeting