21:00:45 <timburke> #startmeeting swift
21:00:45 <opendevmeet> Meeting started Wed Jun 23 21:00:45 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:45 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:45 <opendevmeet> The meeting name has been set to 'swift'
21:00:52 <timburke> who's here for the swift meeting?
21:01:24 <seongsoocho> o/
21:01:40 <acoles> o/
21:01:48 <clayg> o/
21:02:48 <mattoliver> o/
21:02:52 <timburke> as usualy, the agenda's at https://wiki.openstack.org/wiki/Meetings/Swift -- though it's basically just checking in on some of our longer-running threads
21:03:22 <timburke> #topic sharding and shrinking
21:04:05 <timburke> i meant to add the patches mentioned last week to the priority reviews page but i forgot :-(
21:05:22 <timburke> https://review.opendev.org/c/openstack/swift/+/794582 - sharder: avoid small tail shards
21:06:12 <timburke> we (NVIDIA) should be running with that soon -- but i'm still a little skeptical of the default for the new tunable
21:06:49 <clayg> yeah, 100% agree - I don't think keeping "existing bad behavior" is ideal
21:07:06 <clayg> @timburke what default do you think makes sense?  something to do with the configured shrink size or something?
21:07:39 <acoles> I'm unsure about linking it to shrinking - but happy to have a lrger absolute number as default
21:07:45 <acoles> larger*
21:08:04 <clayg> i forget what all of those vars are named - @mattoliver @acoles do you think a "helpful" default would be better?  or because it's all decoupled with all the other values we have to do some validation?
21:08:08 <acoles> even if it is same number as shrink_threshold, I just don't think the two should be couple
21:08:30 <timburke> yeah, i was debating about that -- if we're pushing ops toward absolute values for these config opts anyway, 100k or something seems reasonable
21:08:39 <acoles> +1
21:08:47 <clayg> @acoles are there some combinations that wouldn't make sense tho?  like it can't be bigger than the rows_per_shard (but I think that's already enforced)
21:09:28 <acoles> IIRC I enforced that yes
21:09:57 <acoles> oh, BTW, @timburke yes that piece of code did have an eye towards adding more validations ;)
21:10:29 <timburke> makes sense. do we want to respin it with the higher default before merging?
21:12:00 <acoles> yep I'll do that tomorrow
21:12:23 <timburke> 👍
21:12:26 <acoles> better to have the default start life as we intend
21:12:42 <mattoliver> +1
21:13:08 <timburke> #topic dark data watcher
21:13:24 <acoles> hmmm, anyone running with rows_per_shard < 100k will get burnt
21:13:24 <timburke> i've still not gotten around to reviewing the patches, unfortunately
21:14:02 <acoles> I think I need to catch up with a review too - sorry zaitcev , I've been on vacation
21:14:29 <timburke> acoles, i feel like rows_per_shard = 100k is already pretty low -- though i guess we could make the default min(rows_per_shard, 100k)
21:14:58 <acoles> ok
21:15:43 <timburke> all right. acoles and i will try to get these suckers reviewed
21:15:52 <timburke> #topic open discussion
21:16:14 <timburke> (there wasn't really much to talk about with the relinker, i just forgot to take it off the agenda)
21:16:36 <timburke> what else should we bring up this week?
21:16:54 <clayg> the relinker and dark data were on the agenda?
21:19:07 <timburke> i want to get a release together -- it's been a bit
21:19:46 <timburke> and i've also been digging through our prod logs looking for tracebacks. turns out, we generate a lot of tracebacks
21:21:08 <timburke> and i re-spun the last ARM job to lean in to the py38-ness
21:22:07 <mattoliver> Yeah nice work on that. I've seen some patches in gerrit that address some of those I suspect :)   (re tracebacks)
21:23:09 <timburke> that's the idea :-)
21:23:55 <timburke> all right, if nobody has anything else, we'll make it a short meeting
21:24:08 <acoles> timburke: the arm jobs vote separately right?
21:24:43 <timburke> yup; they'll drop a separate comment, and none of them are currently voting
21:24:53 <acoles> does recheck trigger both?
21:25:06 <acoles> ie arm and the fuller set
21:25:15 <timburke> i figure, assuming everything is pretty stable, we can look at making them voting toward the end of the cycle
21:25:17 <timburke> yup
21:25:40 <acoles> ok
21:26:02 <timburke> all right. thank you all for coming, and thank you for working on swift!
21:26:06 <timburke> #endmeeting