21:00:04 <timburke> #startmeeting swift
21:00:04 <opendevmeet> Meeting started Wed Jul 17 21:00:04 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:04 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:04 <opendevmeet> The meeting name has been set to 'swift'
21:00:12 <timburke> who's here for the swift meeting?
21:00:18 <fulecorafa> Here
21:01:38 <jianjian> o/
21:02:54 <timburke> i neglected to update the agenda from last week, but i think the main topics are mostly the same
21:02:57 <timburke> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:03:12 <timburke> first up, a couple follow-ups
21:03:25 <timburke> #topic account-reaper and sharded containers
21:03:45 <timburke> so we've got the bug report
21:03:46 <timburke> #link https://bugs.launchpad.net/swift/+bug/2070397
21:03:47 <patch-bot> Bug #2070397 - Account reaper do not reap sharded containers (In Progress)
21:04:04 <timburke> and now mattoliver's started working on a patch!
21:04:19 <timburke> #link https://review.opendev.org/c/openstack/swift/+/924034
21:04:20 <patch-bot> patch 924034 - swift - WIP: reaper: Support reaping sharded containers - 1 patch set
21:04:59 <timburke> i've got it on my list of things to look at, but if anyone else can take a look too, i'm sure matt would appreciate it
21:05:33 <jianjian> i can take a look
21:05:37 <timburke> thanks!
21:05:40 <timburke> #topic ISO timestamps and swift-drive-audit
21:06:03 <timburke> again, we've got a bug (thanks, DeHackEd!)
21:06:05 <timburke> #link https://bugs.launchpad.net/swift/+bug/2072609
21:06:06 <patch-bot> Bug #2072609 - swift-drive-audit does not handle ISO timestamps in logs (In Progress)
21:06:26 <timburke> and it took me longer than i meant to get around to it, but now we've also got a patch
21:06:38 <timburke> #link https://review.opendev.org/c/openstack/swift/+/924352
21:06:38 <patch-bot> patch 924352 - swift - swift-drive-audit: Work with ISO timestamps - 1 patch set
21:07:10 <timburke> next up
21:07:39 <timburke> #topic cooperative tokens to reduce thundering herds
21:08:12 <jianjian> btw, what does swift-drive-audit do? first time to hear it
21:08:15 <timburke> jianjian, it's been a bit since i saw anything for those patch -- how's it going? mostly need reviews, or was there anything else you need help with?
21:08:28 <timburke> #link https://review.opendev.org/c/openstack/swift/+/890174
21:08:28 <patch-bot> patch 890174 - swift - common: add memcached based cooperative token mech... - 33 patch sets
21:08:32 <timburke> #link https://review.opendev.org/c/openstack/swift/+/908969
21:08:33 <patch-bot> patch 908969 - swift - proxy: use cooperative tokens to coalesce updating... - 25 patch sets
21:09:26 <timburke> oh -- yeah, swift-drive-audit basically just digs through kernel logs looking for signs that a disk might be failing
21:09:54 <jianjian> cool, is that how swift report failed drives?
21:11:43 <jianjian> for cooperative tokens, I just added some code to improve the retry logic last time, going to test it on staging cluster. this is to address the situation when greenthreads don't get enough scheduling cycles from eventlet, then the request without a token could quite the waiting queue only with one retry.
21:12:05 <jianjian> normally they should get 3 times of retries
21:15:01 <timburke> yeah, it'll search for a couple regexes https://github.com/openstack/swift/blob/master/bin/swift-drive-audit#L209-L212 (or you can configure your own), and if more than error_limit errors are found, it'll unmount the drive for you. that'll get object-servers (eg) responding 507 so the assigned partitions get replicated to the first handoff
21:16:09 <jianjian> got it
21:17:17 <timburke> so for the cooperative token patches, i'm hearing, "do some reviews and look forward to getting some stats/graphs later" :-)
21:17:55 <jianjian> yes, that's right 😄
21:17:58 <timburke> next up
21:18:07 <timburke> #topic pkg_resources warnings
21:18:41 <timburke> the next couple patches have some +2s (thanks matt and zaitcev!)
21:19:39 <timburke> i think this morning i maybe convinced clayg or acoles to take a look for the +A ;-)
21:20:11 <timburke> #link https://review.opendev.org/c/openstack/swift/+/922151
21:20:11 <patch-bot> patch 922151 - swift - Use entry_points for a bunch more executables - 5 patch sets
21:20:18 <timburke> #link https://review.opendev.org/c/openstack/swift/+/922870/2
21:20:18 <patch-bot> patch 922870 - swift - Use entry_points for swift-init - 2 patch sets
21:21:27 <timburke> next up
21:21:34 <timburke> #topic multi-policy containers
21:21:40 <timburke> fulecorafa, how's it going?
21:22:23 <fulecorafa> As of now, no news about this. We spent some time now deploying this feature. It is working fine :)
21:22:51 <timburke> idk, that sounds like nothing but good news ;-)
21:23:09 <fulecorafa> True XD
21:23:19 <timburke> glad its working well so far -- let us know if/when you'd like another set of eyes
21:23:23 <fulecorafa> So yes, we have good news, the feature is working well
21:23:46 <timburke> #topic operator-driven node exclusion
21:24:13 <timburke> i saw there was another message on the ML thread, but haven't gotten to replying yet
21:24:19 <timburke> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/IZUXNXUQFKBZIP6YIOQJMLXPK5RI6M45/
21:24:49 <timburke> if anyone else has thoughts or ideas around it, please chime in too :-)
21:25:23 <timburke> all right, that's all i've got
21:25:27 <timburke> #topic open discussion
21:25:36 <timburke> anything else we should bring up this week?
21:25:52 <fulecorafa> Well if I may make a quick question
21:26:26 <fulecorafa> We're implementing policies for s3api (much like s3 does really, controll access, operations, etc)
21:26:34 <timburke> nice!
21:27:28 <fulecorafa> And we noticed we have 2 different checks to make: one in the actual API when setting the policy, just to validate the document/json; and one in the middlewares (we're making a new one) to actually check access
21:27:30 <jianjian> on operator-driven node exclusion, it may work well for a small cluster, but the static file which requires manual editing won't scale well with a large cluster
21:28:12 <mattoliver> I guess no meeting today, or my client is dead.
21:28:25 <timburke> mattoliver, i think your client died ;-)
21:28:25 <fulecorafa> For this, we made a unified code for checking both. Any recomendations on organizing this?
21:29:01 <mattoliver> oh I send a message and now things are flowing again.. sorry I'm late then
21:29:03 <timburke> fulecorafa, makes sense (both validating on input, and having a separate middleware for enforcement)
21:29:25 <mattoliver> (must be a matrix glitch)
21:29:28 <jianjian> np, matt. good timing for open discussions
21:30:08 <timburke> fwiw fulecorafa there's something kinda similar in https://github.com/openstack/swift/blob/master/swift/common/middleware/acl.py
21:31:18 <fulecorafa> Yeah, we took a look at it timburke as reference. But for our needs we wanted some more customization options, so we made from scratch
21:31:38 <timburke> jianjian, i think that's part of why they've got the API -- pushing the file around wasn't a quick enough response anyway. still has some open questions around trying to keep all proxies up to date, though
21:32:28 <fulecorafa> I think my question is more on where would this make sense to be put, since we're just adding a file into swift/common/middleware, which doesn't seem quite right. We do intend to pitch this upstream in the future
21:34:26 <timburke> is it more s3-compat-specific, or would these policies be enforced when accessing through the swift api, too?
21:35:07 <fulecorafa> As of now, we're making it s3api only for it is the api we use, but we intend on bringing it to swift api too
21:39:04 <timburke> i think somewhere under swift/common/middleware probably *is* a reasonable spot for it -- depending on how closely it has to match s3's schemas, it might even make sense in the s3api subtree
21:39:06 <timburke> i wouldn't worry *too much* about where it lives for now; we can always move it later if it doesn't seem like a good fit later
21:39:38 <fulecorafa> Ok seems good. Thank you
21:41:56 <timburke> all right, i think i'll call it early then
21:42:07 <timburke> thank you all for coming, and thank you for working on swift!
21:42:10 <timburke> #endmeeting