21:01:35 <timburke> #startmeeting swift
21:01:35 <opendevmeet> Meeting started Wed Apr  3 21:01:35 2024 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:35 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:35 <opendevmeet> The meeting name has been set to 'swift'
21:01:43 <timburke> who's here for the swift meeting?
21:01:49 <mattoliver> o/
21:02:04 <jianjian> o/
21:02:45 <timburke> thanks again for covering for me a couple weeks ago mattoliver, and sorry all about missing last week
21:03:03 <timburke> as usual, the agenda's at
21:03:06 <timburke> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:03:15 <timburke> first up
21:03:23 <timburke> #topic caracal release
21:03:24 <mattoliver> no probs :)
21:03:36 <mattoliver> And I've been away, today is my first day back!
21:04:08 <timburke> it's this week! we've had our tag out there a couple weeks or so, but this week is the broader unified release
21:04:10 <jianjian> welcome back, matt!
21:04:34 <mattoliver> Nice
21:04:39 <mattoliver> thanks jianjian
21:05:35 <timburke> as mattoliver was saying a couple weeks ago, it's the best Swift release yet :D
21:05:48 <mattoliver> \o/
21:06:19 <timburke> speaking of broader openstack things...
21:06:23 <timburke> #topic ptg
21:06:28 <timburke> it's next week!
21:06:53 <mattoliver> yeah this snuck up on us. I was completely distracted!
21:06:53 <timburke> and i won't be around for it (spring break; taking the kids up for some skiing)
21:07:14 <timburke> but i still see meeting slots available
21:07:21 <timburke> #link https://ptg.opendev.org/ptg.html
21:07:33 <jianjian> i will be offline for next week too
21:07:42 <mattoliver> Not sure we have time to do the whole doodle time thingy
21:07:44 <mattoliver> oh no
21:08:16 <timburke> if someone (mattoliver?) wants to organize something, i'm sure it could still be done -- maybe talk to diablo_rojo about getting a swift track added
21:09:20 <mattoliver> Yeah, I can go and add some slots and whip together some etherpad links. If you could shoot through the admin zoom code thing if/when you get it timburke
21:09:34 <mattoliver> might be a little under prepped, but can make a showing at least.
21:10:21 <timburke> i'll keep an eye out, but i'm probably not on the list since i didn't respond to the call for participants
21:11:14 <mattoliver> Going to get interesting with out 2 of you, also my summer time daylight saving ends this weeked (so extra confusing) and my grandmother just died (98 so expected) but I assume I'll be flying up to Canberra sometime in the next week or 2, so till be an interesting few weeks :P
21:11:16 <mattoliver> kk
21:12:03 <timburke> yeah, this might also just be one of those times we don't worry about it...
21:12:15 <timburke> next up, ongoing work
21:12:25 <jianjian> sorry to hear that :-(
21:12:39 <timburke> #topic non-ascii keys and s3api
21:12:46 <timburke> #link https://review.opendev.org/c/openstack/swift/+/913723
21:12:46 <patch-bot> patch 913723 - swift - s3api: Fix handling of non-ascii access keys (MERGED) - 3 patch sets
21:13:27 <timburke> merged! fingers crossed that it's the last time we have one of these py3-encoding bugs (but i'm not holding my breath)
21:13:43 <timburke> #topic feature/mpu branch
21:13:46 <mattoliver> lol
21:14:08 <timburke> created! and acoles has been busy spiking out some patches
21:14:17 <timburke> #link https://review.opendev.org/q/project:openstack/swift+branch:feature/mpu+status:open
21:15:49 <timburke> i think we're still kind of feeling out where to draw the line between approving, leaving comments, and actually merging
21:16:59 <mattoliver> Here is a quick link to the PTG topics etherpad I just whipped up.
21:17:04 <mattoliver> #link https://etherpad.opendev.org/p/swift-ptg-dalmatian
21:17:29 <timburke> nice! thanks mattoliver
21:17:33 <mattoliver> Even if you guys wont be around and anyone reading this, any seeding would be greatly appreciated
21:18:09 <jianjian> nice! i will put one topic in
21:18:11 <timburke> 👍
21:19:00 <timburke> #topic drive-full-checker
21:19:03 <timburke> #link https://review.opendev.org/c/openstack/swift/+/907523
21:19:03 <patch-bot> patch 907523 - swift - drive-full-checker - 34 patch sets
21:21:26 <timburke> reviews kinda stalled out here. i'm still a little torn about where we want the source of truth to be for the normal-operations max conns
21:22:05 <mattoliver> yeah sorry, been away. I still think this is super important.
21:22:49 <mattoliver> Definitely will add it as a topic for next week. Any chance you could add your concerns or thoughts we can get that view.
21:23:02 <timburke> and i like making it easier for zigo (and others) to keep clusters from filling up too much
21:23:07 <mattoliver> in the meantime I'll reach back out to our SRE when I get a chance to meet with them today
21:23:17 <mattoliver> +100
21:24:03 <timburke> i did at least write up what our (nvidia nee swiftstack) process looks like: https://review.opendev.org/c/openstack/swift/+/907523/comments/2c281e9f_0a9f64f7
21:24:03 <patch-bot> patch 907523 - swift - drive-full-checker - 34 patch sets
21:24:43 <timburke> and i'm a little worried at the fact that it's constantly overwriting the config
21:25:36 <timburke> and i'd *love it* if we could get some other eyes on it (cc cschwede zaitcev)
21:26:28 <timburke> next up
21:26:43 <timburke> #topic delaying the expirer
21:26:49 <timburke> #link https://review.opendev.org/c/openstack/swift/+/874806
21:26:50 <patch-bot> patch 874806 - swift - expirer: per account and container grace period - 18 patch sets
21:27:23 <timburke> has +2s from both clayg and acoles! but it looks like there's also a rename planned before merging
21:27:58 <timburke> i think that's in p 914768 ?
21:27:59 <patch-bot> https://review.opendev.org/c/openstack/swift/+/914768 - swift - expirer: account and container level delay_reaping - 4 patch sets
21:28:36 <mattoliver> well 2 +2s is nice. Its to match the config option with a form the reaper uses or something if I remember correctly.
21:28:49 <timburke> yup
21:28:56 <timburke> #link https://review.opendev.org/c/openstack/swift/+/874710
21:28:56 <patch-bot> patch 874710 - swift - support x-open-expired header for expired objects - 41 patch sets
21:29:02 <mattoliver> But hopefully that means it should land before next meeting :)
21:29:34 <timburke> opens up an api to be able to actually do something with those expired-but-not-deleted objects
21:29:45 <zaitcev> I'll try to take a look at the expirer at least. I'm busy pilfering code from Swift and applying it to Cinder right now.
21:30:09 <timburke> thanks zaitcev! out of curiosity, code for what?
21:30:17 <mattoliver> lol, umm ok, fair enough :P
21:30:55 <zaitcev> timburke: Encryption. We're adding essentially the same thing for encryption at rest, but for Cinder backups that go into S3.
21:31:03 <timburke> ah, cool
21:31:19 <timburke> that was a fun feature branch :)
21:31:59 <timburke> but yeah, like mattoliver was saying, both these expirer-related patches seem likely to merge in the near future
21:32:35 <timburke> #topic cooperative tokens
21:33:02 <timburke> jianjian's been hard at work trying to get clayg and acoles happy with it
21:33:12 <jianjian> \o/
21:33:13 <timburke> #link https://review.opendev.org/c/openstack/swift/+/890174
21:33:13 <patch-bot> patch 890174 - swift - common: add memcached based cooperative token mech... - 19 patch sets
21:33:31 <timburke> #link https://review.opendev.org/c/openstack/swift/+/908969
21:33:31 <patch-bot> patch 908969 - swift - proxy: use cooperative tokens to coalesce updating... - 11 patch sets
21:34:35 <timburke> anything else you'd like to call out about the patches, jianjian, or do we just need to let y'all do some feedback cycles?
21:34:40 <jianjian> yeah, clay felt the previous interface using context manager was wild and hard to understand, so I converted it to use a class implementation and removed context manager, now he said it's much easier to read now
21:34:43 <mattoliver> seeing as I've been out for more then a week, where is this at jianjian ?
21:34:56 <mattoliver> kk
21:35:36 <jianjian> yes, tim and matt, that'll be great if you two have time to take a look at new implementation
21:36:02 <timburke> cool; i'll see what i can squeeze in
21:36:05 <jianjian> I added a ton of test cases, to verify all different scenarios. the patch is in a much better shape
21:36:18 <mattoliver> kk will add it to my list :) I look forward to looking at it. It's a great idea and great work.
21:36:25 <jianjian> thanks!
21:36:43 <timburke> #topic aws-chunked transfers
21:36:58 <timburke> clayg took a look at the first patch in the chain
21:37:05 <timburke> #link https://review.opendev.org/c/openstack/swift/+/909049
21:37:05 <patch-bot> patch 909049 - swift - s3api: Improve checksum-mismatch detection - 7 patch sets
21:38:13 <timburke> he seemed a little skeptical of the inherit-from-BaseException approach. i'll see whether i can convince him of the merits, 'cause i intend to raise more errors when reading from wsgi.input
21:39:11 <timburke> the longer i've got the chain, the more tempted i am to squash the two additional-checksums patches together
21:39:19 <timburke> #link https://review.opendev.org/c/openstack/swift/+/909801
21:39:20 <patch-bot> patch 909801 - swift - s3api: Add support for additional checksums - 13 patch sets
21:39:22 <timburke> #link https://review.opendev.org/c/openstack/swift/+/909802
21:39:22 <patch-bot> patch 909802 - swift - s3api: Additional checksums for MPUs - 12 patch sets
21:39:57 <mattoliver> Well I like the idea, so we can alway send back the right response.
21:40:31 <zaitcev> I think inheriting from BaseException was cute. But it's just me, and I want to kick the people who write "except Exception" in the nuts.
21:40:52 <mattoliver> lol!
21:41:10 <mattoliver> It is getting long. Which isn't bad. I'll need to refresh myself with the chain. But if you think it can be squashed and makes better sense then go ahead,
21:41:39 <mattoliver> I did something similar in tracing.. athough I may need to break it out some more if I ever what it to land :P
21:42:12 <mattoliver> will tray and get a chance to look through the chain once I've caught up on things.
21:42:14 <timburke> i've been mostly struggling with the last patch in the chain, though, and trying to figure out whether the unit tests are asserting particular responses because that's what AWS does, or because that's what was convenient
21:42:47 <timburke> thanks mattoliver -- the good news is that the probe test failure seems to have gone away!
21:43:10 <mattoliver> \o/
21:43:28 <timburke> something about switching from running on centos 8 to centos 9 fixed it
21:44:16 <jianjian> what kernel version does centos 9 use?
21:44:34 <timburke> i started to poke a little bit at actually understanding it, but gave up when i realized we're unlikely to ever want to roll back OS version in the gate anyway :P
21:45:05 <timburke> i forget... and i'm not actually sure it comes down to kernel versions, or py3 versions, or what
21:46:08 <mattoliver> explains why it always passed on my fedora laptop. But no matter how many times I ran it on a centos 8 vm it passed, so is a mystery :P
21:46:18 <timburke> all i know for *sure* is that on centos 8 i seemed to get an extra child process under my wsgi-server manager process, and it had a blank cmdline under /proc
21:46:24 <jianjian> centos 8 is 4.18, centos 9 is 5.14. but py3 versions definitely matter too
21:46:39 <timburke> py36 vs py39
21:47:24 <timburke> but that's more or less the state of the chain -- though everything still needs a lot of shoring up with unit tests
21:48:03 <timburke> next up
21:48:12 <timburke> #topic part-num support for swiftclient
21:48:18 <timburke> #link https://review.opendev.org/c/openstack/python-swiftclient/+/902020
21:48:19 <patch-bot> patch 902020 - python-swiftclient - support part-num in python swiftClient - 16 patch sets
21:49:28 <mattoliver> Did the partnum stuff make it into the next swift release?
21:49:32 <timburke> i still need to take a look at this -- it'd also be nice to write a follow-on that enabled concurrent downloads
21:50:05 <mattoliver> if not, do we hold off on the swiftclient support until swift has released it?
21:50:22 <mattoliver> I guess it doesn't really matter for nvidia because we run master++
21:50:27 <timburke> mattoliver, no, it'll be part of an eventual 2.34.0
21:50:50 <mattoliver> kk
21:51:19 <mattoliver> I guess it's fine so long as we don't do a swiftclient release (once this lands) before another swift release.
21:51:25 <timburke> we should be fine to merge the client change when it's ready though, as (1) it'll need to be able to deal with pre-part-num clusters anyway and (2) it won't be part of a tagged release yet, either
21:51:42 <mattoliver> yeah ^
21:52:09 <mattoliver> kk
21:52:54 <timburke> alright, last topic i've got
21:53:00 <timburke> #topic next meeting
21:53:22 <timburke> i propose we skip next week for sure, as we usually do PTG weeks
21:53:40 <mattoliver> Well next week is the "ptg" if I can get us added as a track. So yeah skip next week for sure
21:53:57 <timburke> but i *also* won't be around the following week -- up to y'all whether to have a meeting without me or not
21:54:07 <mattoliver> kk
21:54:19 <mattoliver> I'll chair if we decide to :)
21:54:25 <timburke> realizing that i'm already dumping extra work on you mattoliver ;-)
21:54:42 <mattoliver> enjoy your well deserved holiday timburke
21:54:44 <mattoliver> nps
21:54:47 <timburke> all right, that sounds good then
21:54:51 <timburke> #topic open discussion
21:54:58 <timburke> anything else we should bring up?
21:55:25 <mattoliver> nah, like I said I've been away, so mostly catch up.
21:55:48 <mattoliver> let's try and get the topics etherpad fillout out, just in case we can get a track added
21:56:07 <timburke> sounds good
21:56:22 <timburke> all right -- thank you all for coming, and thank you for working on swift!
21:56:25 <mattoliver> And I'll just pick a bunch of slots (if it does). Some apac some US friendly. ie as per normal
21:56:32 <mattoliver> o/
21:56:34 <jianjian> will plant a seed in it 😉
21:56:40 <timburke> 👍
21:56:44 <timburke> #endmeeting