Wednesday, 2023-11-29

opendevreviewMerged openstack/swift master: s3api: return 503 if mpu complete gets 409 deleting marker  https://review.opendev.org/c/openstack/swift/+/90113316:35
opendevreviewAlistair Coles proposed openstack/swift master: DNM: check partnum==1 for non-slo  https://review.opendev.org/c/openstack/swift/+/90217216:44
timburke#startmeeting swift21:02
opendevmeetMeeting started Wed Nov 29 21:02:00 2023 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.21:02
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.21:02
opendevmeetThe meeting name has been set to 'swift'21:02
timburkewho's here for the swift team meeting?21:02
acoleso/21:02
mattolivero/21:03
timburkefirst off, sorry for the last-minute cancellation a couple weeks ago, and the (not explicitly mentioned) cancellation last week for the US holiday21:04
timburkethings have been a little hectic for me21:05
timburkewhich also means i don't have much of an agenda for this week -- though i have the sense that there's been a lot of effort concentrated around the SLO/MPU part-number changes21:05
acolesno worries21:05
mattoliveryeah no worries Tim21:06
mattoliverI've been really distracted the last 2 weeks, so unfortuantly I haven't done much myself anyway.21:07
timburkeis there anything that we'd like to draw extra attention to, or that has questions that need answering that we ought to bring up?21:07
acoleswe've merged the slo refactor that Clay worked so hard on :)21:07
timburke🎉21:07
mattoliver\o/21:07
acolesso our review effort is now focussed on the new partnumber support in SLO, and then s3api21:08
acolesthose are the  indianwhocodes patches21:08
timburkeoh, and gerrit's down for now... i think the SLO one was https://review.opendev.org/c/openstack/swift/+/894570 tho21:09
acolesI think we've all been distracted by holidays and family stuff in last week or so 21:09
-opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be restarting momentarily for a patch update to address a recently observed regression preventing some changes from merging21:10
timburkespeaking of distractions, there's a chance i'll be out for jury duty next week...21:10
timburkei'll set a reminder for myself to get a message out one way or the other my tuesday evening, though21:11
mattoliverkk, or just let me know and I'll pass it along21:11
timburkeso i've just got one other thing i've been thinking about the last few weeks:21:13
timburkei noticed that our "seamless reloads" aren't always so seamless21:13
timburkeit's pretty easy to see: run swift-bench, then reload the proxy part way through -- there'll be a bunch of connection resets21:14
mattoliveroh good test21:15
timburkei'm pretty sure the issue comes down to incoming connections sitting in the old workers' accept queues; when we close the old listen socket, our accept() call immediately starts returning EBADF and all the queued connections get reset21:16
timburkeso i'm going down an ebpf rabbit hole to figure out how we might be able to prioritize the new worker sockets over the old ones21:16
mattoliverahh yeah. We could test that by turning the accept queue down to something tiny21:17
timburkeit'll be an adventure!21:17
mattoliveryay21:17
acolesso we wait for greenthreads to complete in flight requests but those in the accept queue are dropped?21:17
timburkeyup, as best i can tell21:17
mattoliverthe accept queue have been accepted by the OS but we haven't accepted them from our side of the socket. So if we're not pulling requests of the socket anymore, those clients miss out21:18
timburkeeh, the queue doesn't need to be tiny -- in fact, if we make it *too* small, you'll see the bad behavior regardless, as the kernel doesn't have anywhere to put the connection (so it'll just drop it)21:19
acolesright21:19
mattoliveryeah, I just meant to test if its the accept queue21:20
mattoliverI wonder if there is a way to put the socket into close_wait but still deal with the requests (if that is even possible) not sure of the socket state machine. 21:21
timburkei think something like https://paste.opendev.org/show/bcMWJVwkAbAlhpt6xQY0/ shows the bad pretty well, and doesn't even need swift or eventlet21:22
mattoliverAnyway, I super interesting research spike, good thinking Tim. 21:22
timburkebut i think that's all i've got for this week21:24
mattoliverkk, I don't have anything either. A big chuck of downstream work is now completed for me, so hopefully I'll get a bunch of swift time now, so maybe next week I'll have been more productive :) 21:25
timburkeall right, i think i'll call it early21:27
timburkethank you all for coming, and thank you for working on swift!21:27
timburke#endmeeting21:27
opendevmeetMeeting ended Wed Nov 29 21:27:35 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:27
opendevmeetMinutes:        https://meetings.opendev.org/meetings/swift/2023/swift.2023-11-29-21.02.html21:27
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/swift/2023/swift.2023-11-29-21.02.txt21:27
opendevmeetLog:            https://meetings.opendev.org/meetings/swift/2023/swift.2023-11-29-21.02.log.html21:27
acolesok \o21:27
opendevreviewClay Gerrard proposed openstack/swift master: proxy: always use namespaces for updating and listing  https://review.opendev.org/c/openstack/swift/+/90035021:57
opendevreviewClay Gerrard proposed openstack/swift master: sq: do not require auto_shard  https://review.opendev.org/c/openstack/swift/+/90220521:57

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