21:05:45 <timburke> #startmeeting swift
21:05:45 <opendevmeet> Meeting started Wed Feb 21 21:05:45 2024 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:05:45 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:05:45 <opendevmeet> The meeting name has been set to 'swift'
21:05:57 <timburke> sorry, got distracted working on a patch :-)
21:06:06 <mattoliver> how dare you :P
21:06:11 <mattoliver> o/
21:06:38 <timburke> #topic releases
21:07:03 <timburke> it's that time again! i really need to get some new releases proposed soon
21:07:52 <timburke> i think the deadline for client's technically next week, but iirc they like it if i do it a little earlier
21:08:26 <timburke> if you've got any more patches to get in this cycle, now's a good time to get them on people's radars!
21:08:35 <mattoliver> ahh yeah kk. Well we have some python swiftclient patches to land so that's timely ;)
21:09:36 <mattoliver> This one p 833954
21:09:36 <patch-bot> https://review.opendev.org/c/openstack/python-swiftclient/+/833954 - python-swiftclient - Add formpost subcommand to generate signature - 7 patch sets
21:09:55 <mattoliver> and the up-rev patch so I can run pep on py3.12
21:10:27 <mattoliver> p 909498
21:10:27 <patch-bot> https://review.opendev.org/c/openstack/python-swiftclient/+/909498 - python-swiftclient - lint: Up-rev hacking - 2 patch sets
21:10:45 <mattoliver> Thanks for lookin at the last one today timburke
21:10:48 <timburke> yeah, i was about to thank you for that one -- i think it can definitely get in, and it was handy that it kicked the tires on the build-openstack-releasenotes job
21:11:28 <timburke> p 848926 might be nice, too -- and we'll see where p 903770 is
21:11:29 <patch-bot> https://review.opendev.org/c/openstack/python-swiftclient/+/848926 - python-swiftclient - shell: Print friendly account byte quotas - 3 patch sets
21:11:29 <patch-bot> https://review.opendev.org/c/openstack/python-swiftclient/+/903770 - python-swiftclient - Add transaction id to errors - 5 patch sets
21:12:16 <timburke> p 909789 might be good, too, though i'd need to investigate the entrypoints issue some more first
21:12:16 <patch-bot> https://review.opendev.org/c/openstack/python-swiftclient/+/909789 - python-swiftclient - CI: constrain deps for tests - 1 patch set
21:13:22 <timburke> speaking of cycles turning over, it's also election time, so there's another thing i should be doing but haven't 🙃
21:14:03 <mattoliver> lol, timburke for PTL!
21:14:06 <clayg> timburke: PTL for life!  don't quit on us like notmyname 😡
21:14:20 <mattoliver> rofl
21:14:40 <timburke> you two just don't want to find yourselves needing to do it instead ;-)
21:14:57 <clayg> 💯
21:15:00 <mattoliver> that and your great at it!!
21:16:08 <timburke> a swift release will need to happen fairly soon, too -- so if there's anything you feel strongly about, add it to the priority reviews wiki (which i'll update after the meeting to at least pick up those swiftclient patches)
21:16:12 <timburke> #link https://wiki.openstack.org/wiki/Swift/PriorityReviews
21:16:25 <mattoliver> kk
21:17:01 <timburke> (oh hey -- that still has p 809969 on it! we actually merged something we said we cared about!)
21:17:02 <patch-bot> https://review.opendev.org/c/openstack/swift/+/809969 - swift - sharding: don't replace own_shard_range without an... (MERGED) - 16 patch sets
21:17:38 <acoles> wait, you mean we accidentally worked on a priority ;-)
21:17:39 <mattoliver> \o/ the system works.. when we get acoles to fix it :P
21:18:18 <timburke> ok, i'm glad i'm not the only one feeling punchy this week :-)
21:18:54 <clayg> 🤣
21:18:56 <indianwhocodes> o/
21:19:47 <indianwhocodes> https://review.opendev.org/c/openstack/python-swiftclient/+/902020 is on my radar although i don't think it will be ready for the release until i managed to get it all the related part-num patches by next week!
21:19:47 <patch-bot> patch 902020 - python-swiftclient - Support part-num in python swiftClient - 4 patch sets
21:19:51 <timburke> aside from that, i don't think i've really got anything new to bring up -- and since we've got so many, how about i just open up the floor for people to bring up more patches for the priority reviews page ;-)
21:20:02 <timburke> #topic patchfest
21:20:11 <mattoliver> lol
21:20:25 <indianwhocodes> we have https://review.opendev.org/c/openstack/swift/+/906906 that could use another pass
21:20:26 <patch-bot> patch 906906 - swift - s3api: return 400 if partNumber and Range sent - 5 patch sets
21:20:47 <opendevreview> Alistair Coles proposed openstack/swift master: WIP s3api: add more MPU cross-compat  tests  https://review.opendev.org/c/openstack/swift/+/907751
21:21:02 <mattoliver> oh yeah, I was going to take a look at the partnum chain.. will now that indianwhocodes is back!
21:22:05 <timburke> acoles, you reminded me that i never posted my attempt at resolving some of those! i should figure out where i put that...
21:22:18 <mattoliver> timburke: I think we should add your static web tempurl prefix patch. I've +2ed it ;)
21:22:34 <indianwhocodes> I am still going through the chain, the one that has some unresolved comments that i need to address is this one ref : https://review.opendev.org/c/openstack/swift/+/894580
21:22:35 <patch-bot> patch 894580 - swift - s3api: Support GET/HEAD request with ?partNumber - 96 patch sets
21:22:38 <timburke> p 810754
21:22:38 <patch-bot> https://review.opendev.org/c/openstack/swift/+/810754 - swift - staticweb: Work with prefix-based tempurls - 14 patch sets
21:22:51 <mattoliver> thanks, I was looking for it
21:23:44 <jianjian> looking at this one from acoles, https://review.opendev.org/c/openstack/swift/+/890919
21:23:45 <patch-bot> patch 890919 - swift - proxy-server: de-duplicate _get_next_response_part... - 22 patch sets
21:23:54 <mattoliver> I whipped up a "what about something like this" patch based on our SRE wanting to be able to get the error_limited nodes. Tracing will grab that for them too.. but who knows how long that'll take to land. p 909637
21:23:54 <patch-bot> https://review.opendev.org/c/openstack/swift/+/909637 - swift - SIGUSR2 signals print process info on wsgi servers - 2 patch sets
21:23:58 <jianjian> seems I need rebase it first
21:24:45 <mattoliver> That idea comes from a feature of dd. Which if you send a USR1 or USR2 (I forget which) it'll print the status. That's how you used to have to do it before more modern dd.
21:25:14 <mattoliver> We could also extend it to dump the dict and get the running work pids settings.
21:25:42 <indianwhocodes> I want to rebase fix this one before the release next week.p 890919
21:25:59 <timburke> p 890919
21:26:00 <patch-bot> https://review.opendev.org/c/openstack/swift/+/890919 - swift - proxy-server: de-duplicate _get_next_response_part... - 22 patch sets
21:26:00 <mattoliver> Not married to it.. but was kinda interesting I thought. Tim mentioned maybe a domain socket api.. that could work too :)
21:26:19 <acoles> jianjian: indianwhocodes : why does this need rebasing https://review.opendev.org/c/openstack/swift/+/890919 ?
21:26:19 <patch-bot> patch 890919 - swift - proxy-server: de-duplicate _get_next_response_part... - 22 patch sets
21:26:33 <timburke> oh yeah yeah, jianjian mentioned that one, too :-)
21:27:08 <indianwhocodes> it has a merge conflict, but it could use reviews too.
21:27:36 <timburke> i like rebasing -- i could do that instead of writing a nomination email ;-)
21:27:44 <mattoliver> lol
21:27:46 <acoles> I don't see any merge conflict
21:28:09 <indianwhocodes> Am I the only one seeting it, lol ?
21:28:16 <timburke> :-/ gerrit sees it...
21:28:16 <acoles> but yes I'd love reviews
21:28:19 <jianjian> I am seeing it too.
21:28:27 <indianwhocodes> https://usercontent.irccloud-cdn.com/file/HQqRdTNy/Screenshot%202024-02-21%20at%201.28.21%E2%80%AFPM.png
21:28:37 <jianjian> doing rebase, conflicts in test/unit/proxy/controllers/test_base.py
21:29:01 <acoles> ugh yeah, caching :/
21:29:12 <jianjian> ++<<<<<<< HEAD
21:29:12 <jianjian> +        factory = CaptureIteratorFactory(handler._iter_parts_from_response)
21:29:12 <jianjian> +        with mock.patch.object(handler, '_find_source', mock_find_source):
21:29:12 <jianjian> +            with mock.patch.object(
21:29:12 <jianjian> +                    handler, '_iter_parts_from_response', factory):
21:29:14 <jianjian> +                resp = handler.get_working_response(req)
21:29:14 <jianjian> +                resp.app_iter.close()
21:29:16 <jianjian> +        # verify that iter exited
21:29:16 <jianjian> +        self.assertEqual({1: ['next', '__del__']}, factory.captured_calls)
21:29:18 <jianjian> ++=======
21:29:18 <jianjian> +         with mock.patch.object(handler, '_find_source',
21:29:20 <jianjian> +                                mock_find_source):
21:29:20 <jianjian> +             resp = handler.get_working_response()
21:29:22 <jianjian> +             resp.app_iter.close()
21:29:22 <jianjian> ++>>>>>>> c06296250 (proxy-server: de-duplicate _get_next_response_part method)
21:29:23 <indianwhocodes> it is not a biggie
21:29:35 <indianwhocodes> i believe its just one file
21:29:48 <acoles> hah, that'll teach me to merge something! I'll get it sorted
21:30:50 <mattoliver> oh hey I had draft comments on that.. that probably means I started reviewing it at some point.. will do that again.. and maybe reply this time : P
21:31:18 <indianwhocodes> https://review.opendev.org/q/has:draft
21:31:23 <opendevreview> Tim Burke proposed openstack/swift master: proxy-server: de-duplicate _get_next_response_part method  https://review.opendev.org/c/openstack/swift/+/890919
21:31:27 <indianwhocodes> tim taught me that ^
21:31:53 <mattoliver> yeah, or I can just be surprised by past me on occasion :P
21:31:56 <mattoliver> thanks
21:31:57 <timburke> 😳 mine goes on for more than one page...
21:32:10 <indianwhocodes> 😭
21:32:25 <mattoliver> oh mine too
21:32:29 <mattoliver> bugger
21:32:48 <mattoliver> but some are 6 years old.. better hit review on those :P
21:33:26 <mattoliver> woah oldest is 9 years old.. bad Matt!
21:33:28 <clayg> i have a lot of draft comments on patches that are *merged* 🤷‍♂️
21:33:29 <jianjian> Tim fixed merge conflict, nice!
21:33:37 <mattoliver> yeah me too
21:33:44 <jianjian> I had one too :-)
21:34:56 <mattoliver> maybe something like: https://review.opendev.org/q/has:draft+status:open but my gerrit-fu isn't as good as tims
21:36:45 <timburke> seemed pretty good to me :-)
21:37:03 <indianwhocodes> p 836755
21:37:03 <patch-bot> https://review.opendev.org/c/openstack/swift/+/836755 - swift - Add support of Sigv4-streaming - 9 patch sets
21:37:31 <mattoliver> turns out status:open covers merge conflict etc, so yeah seems to work.
21:37:36 <indianwhocodes> Tim, I know you took over and its messy code
21:37:55 <mattoliver> Oh yeah I looked. So are we taking it over then?
21:38:07 <timburke> yeah, i'm still playing with that -- indianwhocodes, if you get a chance, maybe try warp against p 908953
21:38:08 <patch-bot> https://review.opendev.org/c/openstack/swift/+/908953 - swift - Get basic write support for mountpoint-s3 - 2 patch sets
21:38:46 <indianwhocodes> noted.
21:39:14 <opendevreview> Alistair Coles proposed openstack/swift master: proxy: don't use recoverable_node_timeout with x-newest  https://review.opendev.org/c/openstack/swift/+/908287
21:39:18 <mattoliver> Seeing as we have other swift users submitting cool tools like p 907523 is it something we should try and review and get in too?
21:39:18 <patch-bot> https://review.opendev.org/c/openstack/swift/+/907523 - swift - drive-full-checker - 30 patch sets
21:40:05 <mattoliver> maybe I'll poke our SRE for them to take a look too. although our controller probably does similar things
21:40:20 <timburke> my plan for aws-chunked (currently) looks like p 909049, then "add support for additional checksum", then squash together the two patches for aws-chunked
21:40:20 <patch-bot> https://review.opendev.org/c/openstack/swift/+/909049 - swift - s3api: Improve checksum-mismatch detection - 1 patch set
21:40:48 <mattoliver> kk
21:40:51 <timburke> but i owe patchsets for all that work (when i said i got distracted, that was what i was working on :-)
21:41:24 <mattoliver> well that's a good distraction and your definitely forgiven :)
21:41:32 <indianwhocodes> and you got labeled metrics as well, phew
21:42:10 <timburke> i'd very much like to get the fullness checker in for this release -- it's a useful tool that people shouldn't need to reinvent everywhere
21:45:05 <mattoliver> +1
21:45:15 <indianwhocodes> dum question but do you think we might need a doc in there ?
21:45:48 <acoles> I need to drop, bye y'all :wave
21:45:53 <timburke> we could always use more docs ;-)
21:45:57 <timburke> acoles, o/
21:46:00 <acoles> 👋
21:46:33 <jianjian> bye
21:47:58 <timburke> indianwhocodes, whether we should hold off on merging until there are docs kinda depends on the patch -- i generally err toward getting code out there, even if its under-documented, and if i feel like docs are *so* important that we *do* need them, take a stab at writing them myself
21:49:01 <mattoliver> ok big questoin.. if we're going to have a new swift release soon... should we make it the last one with py2 ;)
21:49:17 <mattoliver> maybe too big as question for 10mins left of meeting
21:49:34 <timburke> mattoliver, i'd love to! just as soon as i no longer have py2 code wanting to import it ;-)
21:49:58 <mattoliver> I know.. just hoping we're getting close enough
21:50:16 <timburke> we've already *technically* dropped support for py2 for a while -- those poor fools still relying on py2 CI are on their own ;-)
21:50:20 <mattoliver> and maybe light a fire under ourselves
21:54:54 <timburke> all right, i think we've got most of the patches out -- i think i'll call it (and get on with updating the priority reviews)
21:54:59 <indianwhocodes> I had a minor suggestion for the channel head maybe we can interchange positions for priority reviews with logs, since i feel that takes precedence ?
21:55:50 <timburke> good idea! i'll see whether i can update the topic...
21:56:02 <timburke> thank you all for coming, and thank you for working on swift!
21:56:07 <timburke> #endmeeting