21:00:14 <timburke> #startmeeting swift
21:00:14 <opendevmeet> Meeting started Wed Aug 16 21:00:14 2023 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:14 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:14 <opendevmeet> The meeting name has been set to 'swift'
21:00:21 <timburke> who's here for the swift meeting?
21:00:33 <seongsoocho> o/
21:00:37 <seongsoocho> Hi!
21:00:57 <timburke> hey seongsoocho! i feel like it's been a bit :-)
21:01:06 <mattoliver> o/
21:01:12 <seongsoocho> yes :-)
21:01:18 <acoles> o/
21:01:52 <timburke> all right, first up
21:01:58 <timburke> #topic swift 2.32.0
21:02:10 <timburke> i really, *really* need to actually get a release out
21:02:37 <timburke> i was checking on the bobcat schedule, and we've only got another couple weeks or so
21:02:44 <timburke> #link https://releases.openstack.org/bobcat/schedule.html
21:03:08 <timburke> i should also do a client release
21:03:55 <timburke> so if you've got any patches (or bugs that still need patches) that really should get in this cycle, please let me know!
21:04:17 <timburke> on that topic...
21:04:30 <acoles> fallocate?
21:04:30 <timburke> #topic fallocate_reserve is currently broken
21:04:57 <timburke> #link https://bugs.launchpad.net/swift/+bug/2031035
21:05:04 <kota> wow
21:05:35 <mattoliver> But tim has some patches!
21:05:48 <timburke> it's... not great. but, it was due to (what was supposed to be) some refactoring since 2.31.1 -- so we haven't actually had a release with the bad yet
21:06:34 <timburke> first patch is almost (but not quite) a revert of the patch that caused it
21:06:37 <timburke> #link https://review.opendev.org/c/openstack/swift/+/891356
21:07:12 <timburke> (fwiw, the patch that broke things was https://review.opendev.org/c/openstack/swift/+/879721 )
21:08:14 <timburke> as mattoliver hinted, i've got another fallocate-related patch, but that's fixing a long-standing hole in the protection
21:08:31 <timburke> #topic chunked PUTs and fallocate
21:09:52 <timburke> so, even when fallocate_reserve is working *correctly*, we start blocking PUTs if, once we allocate space for the new write, we'd have less than the reserve amount left free
21:10:56 <timburke> you could run into trouble if the object-server doesn't make any fallocate calls, though -- and the main way that would happen is if it was a chunked PUT (so the server doesn't know how much to allocate)
21:11:58 <timburke> i put up a patch to start returning 507s even when using chunked transfers once we're already past the reserve threshold
21:12:01 <timburke> #link https://review.opendev.org/c/openstack/swift/+/891382
21:12:36 <timburke> but again, this has been some long-standing swift behavior; i don't think it needs to land prior to our next release
21:13:12 <mattoliver> I do like it's a 507 right in the PUT saying hey if we're over sorry can't help ya. And so no extra plumbing through to diskfile or anything.
21:14:43 <timburke> yeah -- long term, i think i might prefer if we *did* start plumbing those config values through diskfile rather than continuing to do this constraints-like global constant-that's-actually-configurable
21:15:36 <timburke> but for now, i'm trying for a more targeted fix, then a follow-on that's more like what we did for fallocate_reserve in the account/container servers
21:15:59 <acoles> timburke: re the first bug fix patch, can you elaborate on why you pulled the code back into utils.__init__ rather than fix the places that set utils.FALLOCATE_RESERVE, utils.FALLOCATE_IS_PERCENT?
21:17:32 <timburke> acoles, same reason i'd left the unused import of fallocate in utils/__init__.py in the original patch -- uncertainty about whether any 3rd party code might be using that function
21:18:03 <acoles> :thum
21:18:11 <acoles> 👍
21:18:27 <mattoliver> oh an I've been testing the chunked case on a vsaio seems to be working. The obj servers are returning 507. so nice.
21:19:00 <timburke> (of course, if they were, i now realize there was a decent likelihood they weren't using it *right*, but that's a separate issue...)
21:19:40 <acoles> OIC, you say that here https://review.opendev.org/c/openstack/swift/+/891356/comment/bc10ff8d_3cd076c6/
21:20:26 <timburke> that's another good question -- what do we think about renaming the function, now that i've split the responsibilities?
21:23:09 <mattoliver> I'm in 2 minds. But backwards compat and the fact the libc namspace in the call means we can have them called the same thing.. that's 1 advantage of using different namespaces.
21:24:38 <acoles> I'm wary of your patch getting bogged down - rename + shim compatibility method could be a follow on
21:24:58 <timburke> that sounds like a good plan to me
21:25:07 <acoles> A comment in libc.fallocate might be useful - "this may not be the fallocate you are looking for"
21:26:05 <timburke> #topic application credentials and access rules
21:26:41 <timburke> i saw a docs patch come by recently that made me aware of (how little i know about) some new keystone features
21:26:50 <timburke> #link https://review.opendev.org/c/openstack/swift/+/891142
21:27:28 <mattoliver> oh I haven't followed keystone development in ages.
21:27:41 <timburke> in particular, it seems like we might want to change some of our recommendations about whether to ask for the service catalog when we're talking to keystone
21:28:02 <timburke> at least, if we want to enable access rules for application credentials
21:28:09 <timburke> #link https://docs.openstack.org/keystone/2023.1/user/application_credentials.html#access-rules
21:28:34 <timburke> so my main question is: has anyone started playing with these?
21:29:47 <mattoliver> not I, but might be a good question to bring up at the next virtual ptg
21:30:11 <timburke> i'm curious about what sorts of new things this could enable, and whether we should be doing anything in our keystoneauth middleware to work with them
21:31:31 <timburke> i know we've been thinking a little more about our auth story at nvidia recently, so figured it might be an interesting data point
21:33:04 <timburke> well, maybe i'll try to get a keystone environment up for myself ahead of the next PTG and play with it :-)
21:33:09 <timburke> speaking of...
21:33:17 <timburke> #topic vPTG
21:33:53 <timburke> in case you missed it, there's going to be another virtual PTG this October, the 23-27
21:34:04 <timburke> register at
21:34:06 <timburke> #link https://ptg2023.openinfra.dev/
21:34:11 <mattoliver> \o/
21:34:22 <seongsoocho> yay~
21:34:31 <kota> nice
21:34:39 <timburke> and i created an etherpad for topics (even if i haven't started populating it)
21:34:42 <timburke> #link https://etherpad.opendev.org/p/swift-ptg-caracal
21:36:09 <timburke> i'll try to remember to create a poll for timeslots for next week
21:36:12 <mattoliver> on nice
21:37:58 <timburke> actually -- i'm not sure the timeslots have been decided yet. yay, i don't have to feel bad about not having done this already! :P
21:38:12 <timburke> all right, that's all i've got
21:38:17 <timburke> #topic open discussion
21:38:24 <timburke> anything else we should bring up this week?
21:38:47 <seongsoocho> It's been a while, everyone. I'm here with the mentees of the openstack upstream contribution mentoring program in Korea.
21:39:03 <seongsoocho> uhyeongjo_ is one of my mentees.
21:39:14 <timburke> hi uhyeongjo_!
21:39:16 <uhyeongjo_> hello !
21:39:22 <seongsoocho> We try to attend weekly meetings as much as possible.
21:39:33 <kota> great
21:39:43 <seongsoocho> We are trying to improve swift recon cli right now. I'll tell you more about it in the next meeting or on IRC.
21:40:04 <acoles> seongsoocho: uhyeongjo_ 👋
21:40:24 <seongsoocho> And we're also trying to solve the low hanging fruit issue in launchpad :-) I'm looking forward to create new swift contributors and enthusiastic fans.
21:40:28 <timburke> that sounds great! i know there are some known issues there, particularly around servers-per-port
21:40:48 <timburke> i love it! thanks seongsoocho and uhyeongjo_!
21:41:00 <seongsoocho> timburke:  oh that's great
21:42:05 <mattoliver> wow, awesome! hey uhyeongjo_ feel free to ping in channel if you need anything
21:42:45 <uhyeongjo_> Thank you ! I will !
21:44:48 <timburke> all right, i think i'll call it
21:44:59 <timburke> thank you all for coming, and thank you for working on swift!
21:45:05 <timburke> and welcome uhyeongjo_ :-)
21:45:10 <timburke> #endmeeting