21:00:10 <timburke> #startmeeting swift
21:00:10 <opendevmeet> Meeting started Wed Feb  2 21:00:10 2022 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:10 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:10 <opendevmeet> The meeting name has been set to 'swift'
21:00:17 <timburke> who's here for the swift meeting?
21:00:22 <seongsoocho> o/
21:00:26 <mattoliver> o/
21:01:33 <acoles> o/
21:02:10 <timburke> as usual, thhe agenda's at https://wiki.openstack.org/wiki/Meetings/Swift
21:02:20 <timburke> first up
21:02:24 <timburke> #topic PTG
21:02:41 <timburke> registration is open!
21:02:44 <timburke> #link https://openinfra-ptg.eventbrite.com/
21:03:07 <timburke> with luck, this'll be our last virtual one!
21:03:29 <timburke> dates are April 4-8
21:03:43 <mattoliver> Time to work on all the last ptg items before the next :p
21:04:40 <timburke> ...yeah, i should go through those aaction items again...
21:04:52 <timburke> but first
21:05:01 <timburke> #topic 2.29.0 release
21:05:12 <timburke> i want to get a release out!
21:05:31 <timburke> changelog updates are up at
21:05:34 <timburke> #link https://review.opendev.org/c/openstack/swift/+/826947https://review.opendev.org/c/openstack/swift/+/826947
21:05:43 <timburke> #undo
21:05:43 <opendevmeet> Removing item from minutes: #link https://review.opendev.org/c/openstack/swift/+/826947https://review.opendev.org/c/openstack/swift/+/826947
21:05:47 <timburke> #link https://review.opendev.org/c/openstack/swift/+/826947
21:06:09 <timburke> it's going to be a great release!
21:06:28 <mattoliver> Nice
21:06:55 <seongsoocho> 🎉
21:07:26 <timburke> if you've got any other work in flight, let's try to get it landed; i'll update the changelog as needed
21:07:34 <acoles> timburke: do we have any outstanding patches we'd like to include before release?
21:07:45 <acoles> oh, ok :)
21:08:07 <timburke> there were a few i was thinking of; i put them on the priority reviews page
21:08:10 <timburke> #link https://wiki.openstack.org/wiki/Swift/PriorityReviews
21:08:14 <mattoliver> Is everything on the priority list done? I should just go check
21:08:21 <timburke> https://review.opendev.org/c/openstack/swift/+/822585 - Trim sensitive information in the logs (CVE-2017-8761)
21:08:29 <timburke> https://review.opendev.org/c/openstack/swift/+/813715 - s3api: Fix multipart upload listings
21:08:36 <timburke> https://review.opendev.org/c/openstack/swift/+/826326 - proxy-server: add stats for backend shard_listing requests
21:08:49 <timburke> though they're all a *little* hairy
21:09:16 <timburke> maybe i'll rearrange my agenda a little ;-)
21:09:28 <timburke> #topic tempurl signatures in logs
21:10:26 <timburke> so i think the solution at https://review.opendev.org/c/openstack/swift/+/822585 is coming along nicely -- though some functions are probably in the wrong place
21:10:53 <timburke> mattoliver took a stab at pulling them out to a new module in https://review.opendev.org/c/openstack/swift/+/825694
21:11:28 <timburke> it creates a decent bit of churn, though, since it's re-homing register_swift_info as well
21:12:01 <mattoliver> If people like the move then it can get squashed down into the first.
21:12:01 <timburke> i wanted to get people's opinion on that -- should we go ahead and squash that down?
21:12:46 <acoles> I have a preference to keep the behavioural change and the code relocation in separate patches, to make review easier
21:13:48 <mattoliver> So leave them as 2 and as they are? Or the other way around? Move then behaviour change?
21:14:29 <mattoliver> The move was also because the new sensitive registers stuff was in the wrong place
21:14:54 <acoles> I don't want to create work for anyone but maybe move existing first then make change and add new functions makes most sense???
21:15:59 <mattoliver> Kk, if everyone else agrees I'll swap em :)
21:16:06 <timburke> mattoliver, do you want  to do that, or should i?
21:16:23 <mattoliver> I'll do it
21:16:37 <acoles> thanks mattoliver
21:16:38 <timburke> 👍 thanks
21:17:17 <timburke> #topic multipart upload listings
21:17:32 <timburke> #link https://review.opendev.org/c/openstack/swift/+/813715
21:18:08 <timburke> i know we've been running with this in prod for a while, but i'm pretty sure i spotted a bug i'd like to fix before landing
21:18:39 <timburke> i'll work on re-spinning that this afternoon (tests will probably be the time-consuming part)
21:19:00 <timburke> #topic proxy-server stats
21:19:53 <timburke> #link https://review.opendev.org/c/openstack/swift/+/826326 adds some stats for listing shard ranges that mirror stuff we've already got for updating
21:20:22 <timburke> but when i put it on the reviews page i think i didn't realize it had some pre-reqs
21:21:10 <timburke> in particular, https://review.opendev.org/c/openstack/swift/+/824608 - Fix statsd prefix mutation in proxy controllers
21:23:07 <timburke> the more i dig into it, the more it seems ripe for a yak-shave
21:23:29 <timburke> and i'm a little worried we're currently adding more hair :-/
21:26:04 <mattoliver> Is the yak changing the metric from what the patch is doing? Because if not maybe we land it to fix then yak-shave follow up?
21:26:09 <timburke> acoles, should i just grin and bear it? can you help me feel better about the logger class hierarchies?
21:27:08 <acoles> looking
21:28:09 <timburke> i think what i *really* want is to pull the statsd client off the logger. start passing around both a statsd client *and* a logger everywhere we currently just have a logger, and have some separate statsd-client wrapper to handle the prefixing of stats
21:29:56 <timburke> having both a PrefixLoggerAdapter and a MetricsPrefixLoggerAdapter feels weird. and i'm a little worried about the thread_locals stuff (though maybe it's unwarranted)
21:31:00 <acoles> re. the conflation of logging and stasd, I also scratched my head at that but I don't think I can justify spending time on unravelling it
21:32:37 <acoles> re. the LogAdapter inheritances, at first glance I'm not sure I see the problem - each adapter wraps another so doesn't need to inherit the other's behaviours
21:33:39 <acoles> there is an assumption that the wrapped logger is a utils.LogAdapter (i.e. has stasd functions and thread locals)
21:34:08 <timburke> the fact that we've got a LogAdapter that's a sibling of our SwiftLogAdapter felt weird to me. pre-existing behavior, but still...
21:36:45 <acoles> on patchset 5 I got feedback that nudged me towards the separate MetricsPrefixLoggerAdapter
21:39:26 <mattoliver> Passing around a statsd client too does sound a bunch of work. I kinda like we can statsd and log from the same client, but we do have adapters all over the place.. but I guess that's what the adapter  pattern does, add functionality.
21:39:41 <acoles> maybe utils.LogAdapter could inherit from utils.SwiftLoggerAdapter and lose the stasd delegate stuff?? IDK, I'd need to study with fresh eyes
21:39:44 <timburke> ok, one other thing that bugged me: the idea of the patch seems to be that `set_statsd_prefix` (or maybe it's the statsd client's `set_prefix`?) is inherently undesireable -- if you're going to set a prefix, it ought to be via a wrapper, it'll be set in __init__, and you shouldn't need to touch it again. but then we still have (and use!) the other interfaces -- we're just more careful about how/when we do it
21:40:28 <timburke> i kinda want to just get rid of the dangerous interface
21:40:41 <acoles> I agree, but not in this patch :)
21:41:07 <timburke> grin and bear it, got it! 👍
21:41:31 <acoles> and, note that elsewhere we are considering introducing the same pattern to set proxy-server backend user agent (i.e. mutate attribute after init)
21:41:43 <acoles> looking for that patch...
21:42:05 <acoles> https://review.opendev.org/c/openstack/swift/+/819387
21:42:20 <mattoliver> Until we can trick(convince) someone to go fix it all ;)
21:42:21 <timburke> all right, enough of me whining about code purity
21:42:29 <mattoliver> Lol
21:42:35 <timburke> #topic updater fairness
21:42:59 <timburke> we've landed a bunch of patches related to this; i think the only outstanding item is the deferral queue
21:43:07 <timburke> #link https://review.opendev.org/c/openstack/swift/+/821736
21:43:15 <acoles> timburke: I'm with you on the purity, just feeling more pragmatic :D
21:43:36 <mattoliver> We should write it down as a bug/tech debt to fix up, so 1, we remember and 2, others can find it to work on it
21:45:04 <timburke> acoles, i just wanted to check in on how the deferal queue is going -- i think i saw some fix ups recently?
21:46:40 <timburke> eh, i should just go review the patch ;-)
21:46:51 <timburke> #topic memcache refreshing
21:47:02 <acoles> there was a little churn triggered by your query about the stats - actually, I've not had chance to catch up with you on that. I left a long comment, and fixed a related thing, but otherwise left it as is ... pending you pointing out my folly
21:47:32 <acoles> I should add some comment in the patch perhaps about how to count things
21:47:45 <timburke> cool -- i'll be sure to review it
21:48:04 <timburke> the shard-range patch has landed now, and the reemoval of pipeline_property is making its way through the gate
21:48:42 <timburke> i wanted to check if anyone thinkgs they'll have time to look at the account/container info patch: https://review.opendev.org/c/openstack/swift/+/821921
21:52:08 <mattoliver> I'll put it on my todo
21:52:17 <timburke> thanks mattoliver
21:52:32 <timburke> that's all i had for this week
21:52:36 <timburke> #topic open discussion
21:52:44 <timburke> anything else we ought to bring up?
21:53:29 <mattoliver> I pushed up a ptg version of serialisation v2. But gzip seek might not be supported in py2
21:53:29 <acoles> thanks for shepherding everything timburke, there's been lots going on !
21:53:46 <mattoliver> So I left some questions in the review.
21:54:17 <mattoliver> Maybe make it py3 only... anyway, maybe something to bring up next meeting.
21:54:48 <timburke> oh yeah, thanks mattoliver! i'd been meaning to loop back to that
21:55:00 <mattoliver> No stress, lots going on
21:55:23 <mattoliver> Would like to progress that hair the so we can benefit from last primaries ;)
21:55:31 <mattoliver> *chain
21:55:34 <acoles> timburke said yoga is the end of the road for py2 🥳
21:56:01 <mattoliver> No idea why phone change that to hair.
21:56:13 <timburke> exactly! anything to make "emergency rebalance" mode less common will be *great*
21:56:17 <mattoliver> Yeah, it'll make things much simpler.
21:56:19 <acoles> I'd like to progress my hair ;)
21:56:32 <mattoliver> Lol
21:56:58 <timburke> acoles, i know the feeling ;-)
21:57:08 <timburke> all right
21:57:19 <timburke> thank you all for coming, annd thank you for working on swift!
21:57:22 <timburke> #endmeeting