Wednesday, 2023-08-16

opendevreviewClay Gerrard proposed openstack/swift master: tests: fix FakeSwift HEAD with query param  https://review.opendev.org/c/openstack/swift/+/88978502:04
opendevreviewClay Gerrard proposed openstack/swift master: WIP: install more mw leak tracking  https://review.opendev.org/c/openstack/swift/+/89150702:27
opendevreviewJianjian Huo proposed openstack/swift master: direct_client: support extra request params for direct_get_container.  https://review.opendev.org/c/openstack/swift/+/89138705:33
opendevreviewJianjian Huo proposed openstack/swift master: direct_client: support extra request params for direct_get_container.  https://review.opendev.org/c/openstack/swift/+/89138705:35
opendevreviewTim Burke proposed openstack/swift master: proxy: Get rid of iter_nodes helper  https://review.opendev.org/c/openstack/swift/+/88531919:09
opendevreviewTim Burke proposed openstack/swift master: proxy: Get rid of MetricsPrefixLoggerAdapter  https://review.opendev.org/c/openstack/swift/+/88532019:09
timburke#startmeeting swift21:00
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.21:00
opendevmeetThe meeting name has been set to 'swift'21:00
timburkewho's here for the swift meeting?21:00
seongsoochoo/21:00
seongsoochoHi!21:00
timburkehey seongsoocho! i feel like it's been a bit :-)21:00
mattolivero/21:01
seongsoochoyes :-)21:01
acoleso/21:01
timburkeall right, first up21:01
timburke#topic swift 2.32.021:01
timburkei really, *really* need to actually get a release out21:02
timburkei was checking on the bobcat schedule, and we've only got another couple weeks or so21:02
timburke#link https://releases.openstack.org/bobcat/schedule.html21:02
timburkei should also do a client release21:03
timburkeso if you've got any patches (or bugs that still need patches) that really should get in this cycle, please let me know!21:03
timburkeon that topic...21:04
acolesfallocate?21:04
timburke#topic fallocate_reserve is currently broken21:04
timburke#link https://bugs.launchpad.net/swift/+bug/203103521:04
kotawow21:05
mattoliverBut tim has some patches! 21:05
timburkeit'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 yet21:05
timburkefirst patch is almost (but not quite) a revert of the patch that caused it21:06
timburke#link https://review.opendev.org/c/openstack/swift/+/89135621:06
timburke(fwiw, the patch that broke things was https://review.opendev.org/c/openstack/swift/+/879721 )21:07
timburkeas mattoliver hinted, i've got another fallocate-related patch, but that's fixing a long-standing hole in the protection21:08
timburke#topic chunked PUTs and fallocate21:08
timburkeso, 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 free21:09
timburkeyou 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:10
timburkei put up a patch to start returning 507s even when using chunked transfers once we're already past the reserve threshold21:11
timburke#link https://review.opendev.org/c/openstack/swift/+/89138221:12
timburkebut again, this has been some long-standing swift behavior; i don't think it needs to land prior to our next release21:12
mattoliverI 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:13
timburkeyeah -- 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-configurable21:14
timburkebut 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 servers21:15
acolestimburke: 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:15
timburkeacoles, 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 function21:17
acoles:thum21:18
acoles👍21:18
mattoliveroh an I've been testing the chunked case on a vsaio seems to be working. The obj servers are returning 507. so nice. 21:18
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
acoles  OIC, you say that here https://review.opendev.org/c/openstack/swift/+/891356/comment/bc10ff8d_3cd076c6/21:19
timburkethat's another good question -- what do we think about renaming the function, now that i've split the responsibilities?21:20
mattoliverI'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:23
acolesI'm wary of your patch getting bogged down - rename + shim compatibility method could be a follow on21:24
timburkethat sounds like a good plan to me21:24
acolesA comment in libc.fallocate might be useful - "this may not be the fallocate you are looking for"21:25
timburke#topic application credentials and access rules21:26
timburkei saw a docs patch come by recently that made me aware of (how little i know about) some new keystone features21:26
timburke#link https://review.opendev.org/c/openstack/swift/+/89114221:26
mattoliveroh I haven't followed keystone development in ages. 21:27
timburkein 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 keystone21:27
timburkeat least, if we want to enable access rules for application credentials21:28
timburke#link https://docs.openstack.org/keystone/2023.1/user/application_credentials.html#access-rules21:28
timburkeso my main question is: has anyone started playing with these?21:28
mattolivernot I, but might be a good question to bring up at the next virtual ptg21:29
timburkei'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 them21:30
timburkei know we've been thinking a little more about our auth story at nvidia recently, so figured it might be an interesting data point21:31
timburkewell, maybe i'll try to get a keystone environment up for myself ahead of the next PTG and play with it :-)21:33
timburkespeaking of...21:33
timburke#topic vPTG21:33
timburkein case you missed it, there's going to be another virtual PTG this October, the 23-2721:33
timburkeregister at21:34
timburke#link https://ptg2023.openinfra.dev/21:34
mattoliver\o/21:34
seongsoochoyay~21:34
kotanice21:34
timburkeand i created an etherpad for topics (even if i haven't started populating it)21:34
timburke#link https://etherpad.opendev.org/p/swift-ptg-caracal21:34
timburkei'll try to remember to create a poll for timeslots for next week21:36
mattoliveron nice21:36
timburkeactually -- i'm not sure the timeslots have been decided yet. yay, i don't have to feel bad about not having done this already! :P21:37
timburkeall right, that's all i've got21:38
timburke#topic open discussion21:38
timburkeanything else we should bring up this week?21:38
seongsoochoIt's been a while, everyone. I'm here with the mentees of the openstack upstream contribution mentoring program in Korea.21:38
seongsoochouhyeongjo_ is one of my mentees. 21:39
timburkehi uhyeongjo_!21:39
uhyeongjo_hello !21:39
seongsoochoWe try to attend weekly meetings as much as possible.21:39
kotagreat21:39
seongsoochoWe are trying to improve swift recon cli right now. I'll tell you more about it in the next meeting or on IRC.21:39
acolesseongsoocho: uhyeongjo_ 👋21:40
seongsoochoAnd 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
timburkethat sounds great! i know there are some known issues there, particularly around servers-per-port21:40
timburkei love it! thanks seongsoocho and uhyeongjo_!21:40
seongsoochotimburke:  oh that's great21:41
mattoliverwow, awesome! hey uhyeongjo_ feel free to ping in channel if you need anything21:42
uhyeongjo_Thank you ! I will !21:42
timburkeall right, i think i'll call it21:44
timburkethank you all for coming, and thank you for working on swift!21:44
timburkeand welcome uhyeongjo_ :-)21:45
timburke#endmeeting21:45
opendevmeetMeeting ended Wed Aug 16 21:45:10 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:45
opendevmeetMinutes:        https://meetings.opendev.org/meetings/swift/2023/swift.2023-08-16-21.00.html21:45
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/swift/2023/swift.2023-08-16-21.00.txt21:45
opendevmeetLog:            https://meetings.opendev.org/meetings/swift/2023/swift.2023-08-16-21.00.log.html21:45
mattoliveryay, breakfast time :) 21:45
opendevreviewJianjian Huo proposed openstack/swift master: direct_client: support extra request params for direct_get_container.  https://review.opendev.org/c/openstack/swift/+/89138722:15
opendevreviewClay Gerrard proposed openstack/swift master: fix swob HEAD handling for leak tracking  https://review.opendev.org/c/openstack/swift/+/89152623:55

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!