Wednesday, 2021-08-18

opendevreviewTim Burke proposed openstack/swift master: Plumb allow_modify_pipeline through run_wsgi/run_server  https://review.opendev.org/c/openstack/swift/+/80454400:09
opendevreviewTim Burke proposed openstack/swift master: DNM: Add MultiprocessInternalClient  https://review.opendev.org/c/openstack/swift/+/80353600:09
opendevreviewMatthew Oliver proposed openstack/swift master: statsd: Make statsd prefix support account interpolation  https://review.opendev.org/c/openstack/swift/+/80494806:24
mattoliver^ thanks kinda just an experiment. Next need to test it out to see if it actaully works as I expect :P06:25
godoghello folks, I ran into an issue on Swift 2.26 where transfer-encoding: chunked is sent on 204, I've opened #1939888 for it and was wondering what you think ? thank you !08:38
clayggodog: i just did a HEAD on my account in my dev environment running master - and did not see a transfer-encoding header in the 204 response 🤔18:06
claygi'm booting up 2.26 now18:06
clayghrm.. same18:06
claygour pipelines look pretty similar18:08
clayggodog: take a closer look at the layers between your client and the eventlet wsgi app that's running the proxy - try to talk directly to it from on a proxy node and see the response is any different (GL!)18:15
opendevreviewClay Gerrard proposed openstack/swift master: ring: store actual ring replica count to better deserialize  https://review.opendev.org/c/openstack/swift/+/80366519:55
timburke_almost meeting time!20:55
*** timburke_ is now known as timburke21:00
timburke#startmeeting swift21:00
opendevmeetMeeting started Wed Aug 18 21:00:22 2021 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
kotao/21:00
mattolivero/21:01
acoleso/21:03
timburkei forgot to update the agenda, sorry -- but mostly i think we just want to follow-up on the patches from last week21:04
timburke#topic container sharding and storage policy reconcililiation21:04
timburkeso we merged the first patch in the chain: https://review.opendev.org/c/openstack/swift/+/80342321:04
timburkehow's the patch to propagate the correct policy to the shards looking? still need review?21:05
timburkehttps://review.opendev.org/c/openstack/swift/+/80074821:05
mattoliverYeah, I've rebased it. just needs some review time21:07
mattoliverunless that happened while I slept :)21:07
timburkei know the first patch also spun off a handful of other patches, most of which either got squashed in or already mereged21:10
timburkei think the one exception is https://review.opendev.org/c/openstack/swift/+/804696 -- acoles, is that mostly a belt & bracers sort of a patch?21:10
acolesmostly belt and braces, seemed like future us could be surprised to deal with an object listing body in a response with a record type of shard.21:13
timburke👍21:14
mattoliverI'll check it out and review it today21:14
acolesI was a little worried about that catching us out given the recursive nature of shard listings21:14
timburkeyeah, seems totally reasonable21:15
acolesbut so far I'm not aware of any bug as such21:15
timburke#topic internal client bottlenecks21:15
acolesI guess if any middleware ever started to pay attention to the record type then there could be issues21:15
timburkei finally got around to doing some benchmarking with my MultiprocessInternalClient21:16
timburkethe context, again, was that i had a single-process, greenthreaded data mover that would get CPU bound. on a little test cluster, switching InternalClient for MultiprocessInternalClient got me a 4-5x speedup!21:17
mattolivernice!21:18
timburkei even managed to do it without any swift changes, though it'll be a lot cleaner once we've got https://review.opendev.org/c/openstack/swift/+/804544 to add some allow_modify_pipeline plumbing through run_wsgi and run_server21:18
acolessounds promising!21:19
timburkethanks for the reviews on that clayg! definitely helped me clean things up a bit and minimize the likelihood that anyone accidentally runs like that for a client-facing proxy21:19
clayg@timburke thanks for flailing along with me21:20
timburkethe main process is still CPU-bound, so next up, i'm going to try fanning out that guy as well21:22
timburkethat's all i've got21:22
timburke#topic open discussion21:22
timburkewhat else should we bring up this week?21:22
mattoliverI'm making prgress on my request tracing POC. Now mostly has opentracing support, I hope to have that working soon.21:24
timburkenice!21:24
mattoliverI've also played with adding statsd account interpolation support https://review.opendev.org/c/openstack/swift/+/80494821:24
mattoliverWhich will allow someone to add accounts to statsd prefixs when it makes sense. In case larger clusters wants to track account usage/datapoints more.21:25
mattoliverwrote code and tests yest.. hopefully test it today. 21:26
mattoliverOh and I saw clayg has pushed and commented on the ring derserialization stuff. So thanks! I'll look at that today too!21:27
mattoliver#link https://review.opendev.org/c/openstack/swift/+/803665 21:29
timburkethe version number bump is definitely something on my mind, since i still want to allow for wider dev_ids in https://review.opendev.org/c/openstack/swift/+/761794 ;-)21:31
timburke(and it runs into similar upgrade problems)21:31
mattoliveroh yeah21:31
clayg@mattoliver do you have any reason to believe someone would want to have that many metric files?  we already have trouble aggregating cluster stats across our number of servers21:31
clayg@timburke awesome!!! ring format v2 here we come! 21:32
timburkehopefully while still being able to write out v1 rings for a while ;-)21:32
mattoliver@clay21:33
mattoliver@clay good question... but something that someone like john is interested in.. but now sure it's exactly what we want yet.. wanted to see how it came out. 21:33
mattoliver*not sure21:34
mattoliver(sorry seems I can't type this early) :P21:34
timburkesurely we can find a way to shard metrics across multiple collectors -- there's definitely an interest in being able to see at a glance which tenant is responsible for a sudden uptick in traffic, for example21:35
mattoliverBut currently if you don't add an {account} nothing changes to what we have today.21:35
timburkeseems about like our usual policy: give ops enough rope to hang themselves :P21:36
mattoliverlol, that's what I do.. I'm software engineer/hangman :P21:36
mattoliverI'll mark it as WIP in any case becasue no doubt it needs more discussion and testing :)21:37
timburkeall right, seems like we're about done21:39
timburkethank you all for coming, and thank you for working on swift!21:39
claygit's possible the way the statsd exporter does metric collection (or how prometheus stores it) makes this exactly what they need/want - but I don't think i'd want that if i was dumping into graphite21:39
timburkedon't forget to put topics on the PTG etherpad21:39
timburke#link https://etherpad.opendev.org/p/swift-ptg-yoga21:39
timburke#endmeeting21:39
opendevmeetMeeting ended Wed Aug 18 21:39:55 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:39
opendevmeetMinutes:        https://meetings.opendev.org/meetings/swift/2021/swift.2021-08-18-21.00.html21:39
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/swift/2021/swift.2021-08-18-21.00.txt21:39
opendevmeetLog:            https://meetings.opendev.org/meetings/swift/2021/swift.2021-08-18-21.00.log.html21:39

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