Wednesday, 2021-12-15

timburke__zaitcev, should i plan on doing a pyeclib release soon-ish to close out https://bugs.launchpad.net/pyeclib/+bug/1933533? or does it not matter that much for you?00:05
zaitcevLike you said, if you fix it in time, I'll never notice it.00:09
timburke__well, the fix should be on master -- the question is whether it'd be good/useful for you to have a new tag that includes it00:11
timburke__(i just went ahead and merged it a few weeks ago: https://review.opendev.org/c/openstack/pyeclib/+/815407 )00:11
zaitcevOh, right. Yes, I'll need a new release but it is not urgent.00:11
timburke__👍 there are a couple things i'm thinking i might want for a new tag: get some py310 testing (so i can justify adding the trove classifier, too), and deprecate jerasure (https://review.opendev.org/c/openstack/pyeclib/+/815410)00:19
timburke__being able to build manylinux wheels would be cool (https://review.opendev.org/c/openstack/pyeclib/+/817498) but it'd also depend on https://review.opendev.org/c/openstack/liberasurecode/+/817497 and getting a new libec release out, and i still need to sort out how to actually *publish them*, so... *shrug*00:20
opendevreviewTim Burke proposed openstack/swift master: proxy: Config options to add a chance of skipping memcache  https://review.opendev.org/c/openstack/swift/+/73680200:48
timburke__huh. the stable/train patch has a job where pip errors out trying to fetch constraints: SSLError(SSLError(1, u'[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:618)'),)': /constraints/upper/train00:52
timburke__looks similar to errors i saw running experimental jobs recently on https://review.opendev.org/c/openstack/swift/+/821478/00:53
timburke__ussuri patch, too: https://zuul.opendev.org/t/openstack/build/16b6636eb6ac4359a7c7d39a5308ffe600:58
opendevreviewMatthew Oliver proposed openstack/swift master: Updater: pop oldest and bucket heapable follow up  https://review.opendev.org/c/openstack/swift/+/82179001:57
opendevreviewMatthew Oliver proposed openstack/swift master: Updater: pop oldest and bucket heapable follow up  https://review.opendev.org/c/openstack/swift/+/82179002:01
opendevreviewMerged openstack/swift stable/xena: Fix cname_lookup test  https://review.opendev.org/c/openstack/swift/+/82175806:57
*** redrobot6 is now known as redrobot10:34
*** tkajinam is now known as Guest851711:58
*** clayg_ is now known as clayg15:00
*** viks___ is now known as viks__15:00
*** erbarr_ is now known as erbarr15:01
*** clarkb is now known as Guest853615:11
*** Guest8536 is now known as clarkb16:18
opendevreviewAlistair Coles proposed openstack/swift master: updater: per bucket deferral queues  https://review.opendev.org/c/openstack/swift/+/82173616:22
opendevreviewAlistair Coles proposed openstack/swift master: updater: per bucket deferral queues  https://review.opendev.org/c/openstack/swift/+/82173616:34
opendevreviewAlistair Coles proposed openstack/swift master: updater: per bucket deferral queues  https://review.opendev.org/c/openstack/swift/+/82173618:21
opendevreviewMerged openstack/swift stable/wallaby: Fix cname_lookup test  https://review.opendev.org/c/openstack/swift/+/82175919:24
opendevreviewMerged openstack/swift master: Move CI from CentOS 8 to CentOS 8 Stream  https://review.opendev.org/c/openstack/swift/+/82096420:51
seongsoochogood morning20:56
timburke#startmeeting swift21:00
opendevmeetMeeting started Wed Dec 15 21:00:07 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
seongsoochoo/21:01
acoleso/21:01
mattolivero/21:01
timburkeas usual, the agenda's at21:02
timburke#link https://wiki.openstack.org/wiki/Meetings/Swift21:02
timburkefirst up21:02
timburke#topic object-updater fairness21:02
timburkeyou may have noticed a buynch of patches lately fiddling with how the object-updater handles ratelimiting21:03
kotamornin21:03
opendevreviewAlistair Coles proposed openstack/swift master: updater: per bucket deferral queues  https://review.opendev.org/c/openstack/swift/+/82173621:04
timburkethere's enough of them floating around now that it can be a little tricky to see what's the main thrust of the effort ;-)21:04
acolesthere's one right there ^^ :D21:05
mattoliverlol21:05
timburkemy impression is that that's the end of the main chain, is that right? and we'll likely squash/abandon most of the others?21:06
timburkethere are three main ideas:21:06
acolestimburke: correct, that's the end and if we settle on the idea will be squashed with parent and grandparent21:07
timburkehttps://review.opendev.org/c/openstack/swift/+/820962/ sets a per-container ratelimit on updates -- and when the limit is exceeded, we drop updates to be picked up on the next cycle21:07
acolesmattoliver: this could probably be abandoned (but was very useful!)21:07
acoleshttps://review.opendev.org/c/openstack/swift/+/821790/221:08
mattoliveryeah, kk no problem21:08
mattoliverI'll abandon that and the other priority queue chain seeing as yours incorparates the best of all the worlds :)21:08
timburkehttps://review.opendev.org/c/openstack/swift/+/821326/ and https://review.opendev.org/c/openstack/swift/+/821480/ should probably get squashed together -- they let us keep some of that deferred work in our head so we can make effective use of the time that we'd otherwise be sleeping for the sake of the configured interval21:09
timburkeand https://review.opendev.org/c/openstack/swift/+/821736/ better prioritizes that deferred work so we don't burn a bunch of CPU shuffling a deque21:10
timburkeoverall, the expectation is that we'll have two ratelimits for updaters: one that protects us from using up all the iops searching for work to do, and another that protects the container servers from getting overloaded21:12
timburkeand you can adjust the interval as something of a slider to decide how much time you want to devote to overloaded containers vs responsive containers21:13
timburkei don't have much to add to all that -- i think we've got plenty of attention on it and it's moving in a good direction. just wanted to keep everyone else in the loop, too :-)21:14
timburke#topic keeping things in memcache21:15
timburkewe've seen some bad thundering-herd behaviors when items fall out of memcached -- but just increasing cache time is risky since it increases the likelihood that the cache will be stale21:16
timburkea while back i started playing with an idea to randomly skip going to memcache sometimes, so we'd get a refresh before things fall out21:17
timburke#link https://review.opendev.org/c/openstack/swift/+/73680221:17
mattolivermakes a bunch of sense, under high load when something expires out of cache the server can get hit quite hard. keeping it hot seems like a win.21:19
mattoliverI'll review the patch today21:19
timburkeincorporating some of the early feedback got a little hairy, though -- needed to start  digging through app.app.app... to find config values for every time a middleware wants to call get_container_info21:19
timburkei think i've got a plan, though, and it involves getting rid of pipeline_property :-D21:19
acolesdo it!21:20
mattoliverlol, should we revisit your old less brittle pipeline_property21:20
timburkeso mattoliver, i wouldn't worry about reviewing it until i push up a new chain ;-)21:20
mattoliverkk21:20
mattoliveron the same vein as this, I've been working on optionally putting error limited into memcache so things can globally share this info21:21
mattoliverAnd even playing with the updater sharing the same error limiting info, so if a container server is overloaded and say a proxy knows it, so does others rather then having to each figure it out themselves (by failing to hit it 11 times by default). 21:22
mattoliverSo if anyone gets bored: https://review.opendev.org/c/openstack/swift/+/82048621:22
timburkedefinitely seems interesting21:23
timburkenext up21:23
acolesas an FYI, I worked on a different approach to keeping shard ranges in cache here https://review.opendev.org/c/openstack/swift/+/817294, but we had some concerns about the bleeding of concerns from proxy to container server so I am currently hoping timburke 's randomised approach works out21:23
timburke#topic tempurl signature logging21:23
timburke#link https://review.opendev.org/c/openstack/swift/+/81747621:23
timburkehas anyone had a chance to revisit this patch?21:23
mattoliverI reviewed it at some point, but got distracted. I'll loop back and see where it's at today if you like21:25
timburkethat'd be great, thanks mattoliver!21:25
timburke#topic recon and servers_per_port21:26
timburkei still need to follow up on https://review.opendev.org/c/openstack/swift/+/81888121:26
timburkebut does anyone have concerns about the approach of only querying once per ip?21:28
timburkei could imagine deploying with not all disks available to all ports, but i'm not sure that anyone actually *does*21:29
timburkei guess i won't worry about it then21:30
timburke#topic request tracing21:31
timburkemattoliver, when's that talk again?21:31
mattoliverLet me find the link :)21:31
timburke#link https://lca2022.linux.org.au/schedule/presentation/32/21:32
timburkenext month!21:32
mattoliveroh thanks, yeah 15th Jan 21:32
mattoliverIts cause I tweeted about the tracing at the PTG so now I'm turning it into a talk.21:33
timburkeneed anything to help prep for it?21:33
mattoliverPlus side is, it's getting me to clean up and fix a bunch. 21:33
mattolivernot at this point. I don't plan on it merging anytime soon. Trying to debug why bulk and slo seem to loose the known spans. 21:34
mattoliverdebugging they're there at the start of the middleware, but gone in a function call in the same middleware.. so need to dig into how that can happen. 21:35
timburkemy best guess would be something with the greenthreadpools -- i seem to remember that being tricky when poking at similar ideas with zipkin21:35
timburkeshould i keep it on the agenda for next week?21:35
mattoliveryeah, I've got some interesting scafalding to get around some green pool things.21:36
mattoliverthis seems to be different (but probably isn't once I dig in some more).21:36
timburkeall right, that's all i've got21:37
timburke#topic open discussion21:37
mattoliverwas wanting to do a bulk extract as a interesting example in the talk.. but need to get it working first :P21:37
mattoliveryeah, keep it in the agenda and it'll motivate me to fix it :P21:37
timburkewhat else should we bring up this week?21:37
zaitcevNothing for me.21:38
mattoliverI'm good21:38
timburkeoh -- speaking of next week, should we bother meeting? or should we next meet next year?21:39
mattoliveroh yeah, next week I'll be driving to my parents (10 hours away). so probably not around21:39
mattoliverSo I'm ok for skipping21:39
timburkei'm voting for next year :-)21:41
acoles+1 or skipping21:41
timburkeenjoy the end of the year everyone!21:42
kotaI'm ok21:42
seongsoochome too :-) 21:42
timburkeall right -- thank you all for coming, thank you for working on swift, and talk to you next year!21:42
timburke#endmeeting21:42
opendevmeetMeeting ended Wed Dec 15 21:42:41 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:42
opendevmeetMinutes:        https://meetings.opendev.org/meetings/swift/2021/swift.2021-12-15-21.00.html21:42
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/swift/2021/swift.2021-12-15-21.00.txt21:42
opendevmeetLog:            https://meetings.opendev.org/meetings/swift/2021/swift.2021-12-15-21.00.log.html21:42
opendevreviewTim Burke proposed openstack/swift master: proxy: Add a chance to skip memcache when looking for shard ranges  https://review.opendev.org/c/openstack/swift/+/73680223:21
opendevreviewTim Burke proposed openstack/swift master: Get rid of pipeline_property  https://review.opendev.org/c/openstack/swift/+/82192023:21
opendevreviewTim Burke proposed openstack/swift master: proxy: Add a chance to skip memcache for get_*_info calls  https://review.opendev.org/c/openstack/swift/+/82192123:21

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