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