21:00:02 <timburke> #startmeeting swift
21:00:02 <opendevmeet> Meeting started Wed Jul 24 21:00:02 2024 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:02 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:02 <opendevmeet> The meeting name has been set to 'swift'
21:00:08 <timburke> who's here for the swift meeting?
21:00:15 <kota> o/
21:00:20 <fuleco> o/
21:00:43 <mattoliver> o/
21:01:31 <timburke> as usual, the agenda's at
21:01:33 <timburke> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:01:47 <timburke> and i even remembered to update it this week ;-)
21:01:59 <timburke> first up
21:02:07 <timburke> #topic pkg_resources warnings
21:02:48 <timburke> there's been a good bit of progress! p 922151 p 922870 and p 922871 all merged
21:02:48 <patch-bot> https://review.opendev.org/c/openstack/swift/+/922151 - swift - Use entry_points for a bunch more executables (MERGED) - 5 patch sets
21:02:49 <patch-bot> https://review.opendev.org/c/openstack/swift/+/922870 - swift - Use entry_points for swift-init (MERGED) - 2 patch sets
21:02:49 <patch-bot> https://review.opendev.org/c/openstack/swift/+/922871 - swift - Pull swift-dispersion-populate to its own module (MERGED) - 2 patch sets
21:03:07 <timburke> thanks for the reviews mattoliver, zaitcev, clayg!
21:03:22 <timburke> next in the chain is
21:03:24 <timburke> #link https://review.opendev.org/c/openstack/swift/+/922872
21:03:24 <patch-bot> patch 922872 - swift - Pull swift-*-info scripts into swift.cli.info - 3 patch sets
21:03:47 <timburke> and then to complete the entry_point transition
21:03:49 <timburke> #link https://review.opendev.org/c/openstack/swift/+/924776
21:03:50 <patch-bot> patch 924776 - swift - Move remaining bin scripts to cli modules - 3 patch sets
21:04:38 <mattoliver> I worked my way up the chain yesterday.
21:04:41 <timburke> on top of that i've now got p 924795 to remove all of bin/ -- but i'm a little torn
21:04:41 <patch-bot> https://review.opendev.org/c/openstack/swift/+/924795 - swift - Remove legacy bin/ scripts - 2 patch sets
21:04:50 <mattoliver> What was the plan with the last one, yeah that one?
21:05:08 <mattoliver> do we rip the bandaid or support them for a few releases?
21:06:01 <timburke> yeah, so -- i'm of two minds. on the one hand, we've had at least one case of people relying on them existing (though they switched to using the actual installed script)
21:07:29 <timburke> on the other, i don't really *want* to have them any longer than necessary. if the contract is "pip install swift leaves me with executables on my PATH", all those patches preserve it
21:08:22 <timburke> and using bin scripts directly from a swift checkout seems very much a developer workflow, not something we'd expect operators to be doing
21:08:46 <mattoliver> hmm
21:09:07 <timburke> what're everyone else's thoughts about it?
21:10:18 <mattoliver> well devs can now just point to the cli scripts themselves and call the main
21:10:22 <mattoliver> which is probably nicer anyway
21:10:44 <mattoliver> BUT if there is 1 person out there we know about there could be more. So feel torn.
21:11:20 <fuleco> I taking a look at the patch...
21:11:38 <timburke> fwiw, the one and only case i'm aware of was from years ago: p 416787
21:11:38 <patch-bot> https://review.opendev.org/c/openstack/devstack/+/416787 - devstack - Use the installed swift scripts (MERGED) - 1 patch set
21:11:55 <mattoliver> Do we add a decprecated to them in the next release notes and remove them the one after? BUT on the other hand I agree, we're still providing all the scripts just via pip.
21:12:50 <mattoliver> It is git. we could rip them out and if anyone complains revert :P But I guess that's hard because it'll have to wait a release
21:13:26 <fuleco> It seems like the code is simply moved around right? I personally think that there is no reason to keep it as individual scripts specifically. Provided the migration to new versions can be solved at most with a search/replace operation I personally think we should proceed with this
21:13:27 <timburke> yeah, that's the other route i was considering. call out the deprecation in release notes, add warnings in the bin/ scripts, wait a release or two, *then* remove
21:13:48 <fuleco> As mattoliver said, maybe release a deprecation notice before though
21:14:24 <kota> +1
21:14:26 <mattoliver> The generated scripts are basically identical to the existing ones
21:15:14 <mattoliver> Anyone packaging swift will have setuptools / pip install and generate the scripts. And we don't point to the old ones in setup.cfg anymore..
21:16:00 <mattoliver> so only only people who will notice any difference are people checking out the code and then trying to run (which is that really supported)?
21:16:46 <mattoliver> So the "we're already supporting/providing the same bin scripts" is a strong one too.
21:17:06 <mattoliver> fuleco and kota seem to +1 the deprecation route, so let's go with that :)
21:18:00 <timburke> all right, i can add that. thanks for thinking about it with me everyone!
21:18:09 <timburke> next up
21:18:21 <timburke> #topic iso timestamps and swift-drive-audit
21:18:30 <timburke> #link https://review.opendev.org/c/openstack/swift/+/924352
21:18:30 <patch-bot> patch 924352 - swift - swift-drive-audit: Work with ISO timestamps (MERGED) - 1 patch set
21:19:30 <timburke> quick update: it merged! and i made sure that the change was reflected when it moved around in p 924776
21:19:30 <patch-bot> https://review.opendev.org/c/openstack/swift/+/924776 - swift - Move remaining bin scripts to cli modules - 3 patch sets
21:20:02 <timburke> thanks mattoliver, jianjian, and DHE for taking a look
21:20:12 <timburke> next up
21:20:18 <timburke> #topic py313
21:20:18 <mattoliver> nps
21:20:44 <timburke> i said a while ago that i'd try out swift under py313, and i finally did!
21:21:02 <timburke> the long and short of it is that we're mostly still blocked waiting on deps to support it
21:21:21 <mattoliver> kk,  I guess that's expected
21:21:49 <timburke> cffi is currently busted, preventing xattrs from building -- but they've got a merged-but-not-yet-released fix
21:21:57 <timburke> #link https://github.com/python-cffi/cffi/issues/95
21:22:20 <timburke> greenlet is also busted, but vstinner is working on it
21:22:24 <timburke> #link https://github.com/python-greenlet/greenlet/pull/396
21:22:44 <timburke> eventlet's busted, too
21:22:46 <timburke> #link https://github.com/eventlet/eventlet/issues/964
21:23:28 <mattoliver> So all the things are broken :P
21:23:29 <timburke> there's a PR to get over the immediate error, and by taking all three i could at least get some unit tests running!
21:23:44 <mattoliver> nice one
21:24:11 <timburke> not the full suite though; that bombs out during collection because webob (required by keystonemiddleware, required for some s3api tests) still uses the now-removed cgi module
21:24:39 <timburke> #link https://github.com/Pylons/webob/issues/437
21:25:36 <timburke> but -- with at least *some* tests running, it did turn out a couple new issues
21:25:47 <timburke> #link https://review.opendev.org/c/openstack/swift/+/924768
21:25:47 <patch-bot> patch 924768 - swift - Implement context manager protocol for logging mut... - 2 patch sets
21:25:54 <timburke> #link https://review.opendev.org/c/openstack/swift/+/924771
21:25:54 <patch-bot> patch 924771 - swift - Pass timeout as kwarg - 2 patch sets
21:26:40 <timburke> the second one just resolves a deprecation warning, but it seems best to nip it in the bud
21:27:23 <mattoliver> oh cool
21:27:58 <timburke> the only other known-issue is our own use of the cgi module -- and jianjian and i had some good back-and-forth on p 887908 recently
21:27:58 <patch-bot> https://review.opendev.org/c/openstack/swift/+/887908 - swift - Stop using cgi.parse_header - 4 patch sets
21:28:01 <mattoliver> great stuff timburke
21:30:48 <timburke> the only other thing i've found so far is a hang in test/unit/common/test_utils.py::TestUtils::test_monkey_patch -- presumably because eventlet isn't fully happy yet
21:31:54 <timburke> that's as far as i've gotten so far -- haven't tried to functionally validate yet, though that hang makes me pessimistic
21:32:43 <timburke> the remaining items, i don't know that there's a whole lot to report
21:32:55 <mattoliver> either way, its a great steps forward
21:33:12 <mattoliver> and you found some needed improvements, so that's a win
21:33:16 <mattoliver> thanks for digging in!
21:33:26 <timburke> 👍
21:33:34 <timburke> we could check in real quick in case i'm wrong, though
21:33:45 <timburke> #topic account-reaper and sharded containers
21:34:14 <timburke> mattoliver, i'm guessing you haven't had a chance to do much with p 924034? i know *i* haven't
21:34:15 <patch-bot> https://review.opendev.org/c/openstack/swift/+/924034 - swift - WIP: reaper: Support reaping sharded containers - 1 patch set
21:34:45 <mattoliver> Oh yeah, I've been playing with is. My first attempt is that one, and it talks direct client
21:35:09 <mattoliver> but there is a bunch of recursion using direct client which is a little messy.
21:35:27 <mattoliver> So makes me think it might just be better to use internal client that can already speak sharding
21:35:50 <mattoliver> But that involves adding an interenalclient to the reaper (which I guess I'm not against).
21:36:18 <mattoliver> So the plan is to do a second internal client version and see how that shakes out, and it might look cleaner.
21:36:25 <timburke> i think the main issue there would be the early 410, but presumably we could get around with some x-backend- header flag
21:36:47 <mattoliver> yeah
21:37:34 <mattoliver> and if I did squash an internal client in there, then maybe it makes sense to use it everywhere in the reaper and remove direct client (or maybe having both is ok).
21:37:44 <timburke> adding another internal_client user seems perfectly reasonable, though; that seems more and more like a thing that we just expect to have available
21:38:11 <timburke> would probably be good for swift-account-audit to use it, too -- could resolve a few bugs
21:38:24 <mattoliver> yeah, esp because sharding it mostly implemented in the proxy, so internal client gives us that.
21:38:38 <mattoliver> +100
21:38:43 <mattoliver> I noticed that that otherday too
21:39:11 <mattoliver> So my plan is to attempt an internal client version. Maybe we can make a decision on direction then
21:39:21 <timburke> 👍
21:39:22 <mattoliver> I'll try and get something at least basic up by next meeting
21:39:53 <timburke> #topic multi-policy containers
21:40:14 <timburke> fuleco, i'm guessing you're still good for now?
21:40:29 <fuleco> Yep, all good.
21:40:55 <fuleco> We're working a bit on our clients for now, so little news on my side
21:41:03 <timburke> 👍
21:41:33 <timburke> #topic operator node exclusion
21:41:44 <timburke> and i still haven't responded to the latest on the ML
21:42:05 <timburke> i should try to do that this week
21:42:17 <timburke> in part because
21:42:23 <timburke> #topic no meeting next week
21:42:31 <timburke> i'm going to be out on vacation next week
21:42:35 <mattoliver> oh yeah.. I was going to read that, opened it in a tab and never did... sorry too
21:42:38 <mattoliver> oh kk
21:42:54 <mattoliver> that gives me 2 weeks to get the internal client reaper written :P
21:43:00 <timburke> i suppose that doesn't preclude there being a meeting, but i won't be around to chair it :-)
21:43:27 <mattoliver> Well let's plan to skip it for now. If anything major does come up, I'm happy to chair.
21:43:37 <timburke> sounds good, thanks mattoliver
21:43:40 <timburke> that's all i've got
21:43:45 <timburke> #topic open discussion
21:43:52 <timburke> anything else we'd like to bring up?
21:44:02 <mattoliver> Gives kota  and I a good chance to sleep in :)
21:45:01 <mattoliver> The qatar summer students are finishing up this week. But a few have said their interesting in continuing to work to 1 get things finished and to tackle some more of the projects we set.
21:45:26 <mattoliver> * and 2 tackle some more..
21:46:00 <mattoliver> So I think it went well, esp if they want to keep hacking on Swift :)
21:46:25 <mattoliver> Although it does mean I have to write some kind of report for their uni or something this week.
21:47:11 <timburke> oh, right! i should take a look at the still-open patches today
21:47:19 <mattoliver> yeah, there's
21:47:36 <mattoliver> #link https://review.opendev.org/c/openstack/swift/+/922833
21:47:36 <patch-bot> patch 922833 - swift - Periodic reaper recon dump showing current progress - 7 patch sets
21:48:10 <mattoliver> #link https://review.opendev.org/c/openstack/swift/+/924549
21:48:10 <patch-bot> patch 924549 - swift - WIP: account_quota: migrating quota_bytes and quot... - 2 patch sets
21:48:30 <mattoliver> ^ that's the follow up to move things to the x-account-quota-namespace
21:48:55 <timburke> #link https://review.opendev.org/c/openstack/swift/+/924431
21:48:55 <patch-bot> patch 924431 - swift - container storage-policy modification operator tool - 1 patch set
21:48:59 <mattoliver> #link https://review.opendev.org/c/openstack/swift/+/924431
21:48:59 <patch-bot> patch 924431 - swift - container storage-policy modification operator tool - 1 patch set
21:49:06 <mattoliver> Oh you beat me :P
21:49:11 <timburke> thanks mattoliver, and thanks for mentoring them this summer!
21:49:19 <mattoliver> Yeah and that one
21:49:40 <mattoliver> nps, my timezone seemed to match better so it made sense. And they were good peeps.
21:50:46 <mattoliver> that all I got
21:50:53 <timburke> all right, i think i'll call it then
21:50:56 <timburke> thank you all for coming, and thank you for working on swift!
21:51:03 <timburke> #endmeeting