21:00:38 <timburke_> #startmeeting swift
21:00:38 <opendevmeet> Meeting started Wed Jun  8 21:00:38 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:38 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:38 <opendevmeet> The meeting name has been set to 'swift'
21:00:46 <timburke_> who's here for the swift meeting?
21:00:56 <kota> hi
21:02:30 <timburke_> as usual, the agenda's at
21:02:34 <timburke_> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:02:43 <acoles> I'm here for a while
21:02:51 <timburke_> first up
21:03:01 <timburke_> #topic tempurl sha1 deprecation
21:03:46 <timburke_> so i realized we probably should have added client support before we went and removed sha1 from the server defaults
21:04:05 <timburke_> and i proposed https://review.opendev.org/c/openstack/python-swiftclient/+/845157 to remedy that
21:06:04 <timburke_> in general, i think clayg wasn't real happy with how https://review.opendev.org/c/openstack/swift/+/525771 shook out
21:06:14 <timburke_> but it's not clear to me what lessons there are to be learned as we try to do something similar for formpost
21:07:45 <acoles> client support first would have helped i guess
21:07:57 <timburke_> maybe we could also emit some stats about what algorithms are in use, so ops can feel confident that their users have transitioned?
21:08:26 <acoles> yeah, I'm not sure - were we logging warnings if sha1 was still configured after deprecation?
21:08:44 <timburke_> or that the feature isn't being used
21:08:46 <acoles> but logging stats about clients would be cool
21:10:09 <timburke_> i think clay's issue was with the deprecation and the removal from defaults coming in one patch -- but i feel like our default configs shouldn't emit deprecation warnings as a matter of principle
21:11:05 <kota> i see
21:11:12 <acoles> I guess we could first introduce the facility to explicitly opt in for the legacy support, and warn if client uses legacy but its not explicitly configured, then in a later release flip to *requiring* explicit opt in. That would be a softer bump.
21:12:44 <timburke_> would there be value in me writing that up for tempurl? we haven't had a tagged release since the deprecation/removal-from-defaults landed
21:13:38 <timburke_> if we *do* do that, how long should we wait before requiring the explicit opt-in?
21:14:23 <acoles> IDK, it feels like a lot of work in lieu of ops not reading upgrade impacts
21:14:44 <kota> ;/
21:15:12 <timburke_> meanwhile, i'm pretty sure sha1 was a bad idea (or at least, not a great idea) even when swift was first released :-(
21:15:27 <acoles> hmm
21:16:02 <timburke_> it's an appeal to authority, but: https://www.schneier.com/essays/archives/2004/08/cryptanalysis_of_md5.html
21:16:18 <timburke_> as of 2004, "It’s time for us all to migrate away from SHA-1."
21:17:59 <acoles> being contrarian, we could just add the ability to opt *out* of sha1 (if we don't already have that) and leave it to ops to do the right thing???
21:18:27 <zaitcev> I'm not militant about client first. I think it's sufficient if curl can be used.
21:18:51 <zaitcev> The shift in the defaults thanks to TripleO people being lazy is something that bothers me.
21:19:58 <timburke_> right -- you'd brought that up in the review, too. i'm not clear on when we *would* feel safe removing it from defaults, though
21:21:10 <timburke_> idk -- i'll hash it out with clay some more, too. it *does* make me glad that we broke up the formpost changes into a few different patches
21:21:21 <timburke_> speaking of
21:21:45 <timburke_> #topic formpost digest algos
21:22:17 <timburke_> i think i'm happy with https://review.opendev.org/c/openstack/swift/+/838434 now
21:22:49 <timburke_> the formats of signatures match tempurl, and i cleaned up the tests a little
21:24:41 <timburke_> i think both mattoliver and i have touched it a lot -- anyone else have some review bandwidth for it?
21:25:05 <timburke_> otherwise, maybe we'll just get the two of us on board and call it good enough ;-)
21:25:30 <acoles> sorry, I'm not going to be able to help with that for a while
21:27:38 <timburke_> all right, we'll sort it out -- that first patch in particular is purely additive, so i'm not too worried
21:28:31 <timburke_> #topic backend ratelimiting
21:29:30 <timburke_> to my knowledge, we still haven't gotten to doing any load testing with it yet. i still want to see how it actually behaves before merging
21:29:38 <acoles> +1
21:30:11 <acoles> I've been doing some thinking about how the proxy error limiting is going to react to the 529 responses and I still feel we should be cautious.
21:31:56 <timburke_> and https://review.opendev.org/c/openstack/swift/+/839088 is the follow-up to have 529 not count for error-limiting
21:31:58 <acoles> It's all about the timescales - error limiting takes a node out for one minute which may be longer than needed after a burst of heavy load on a hotspot device
21:32:51 <acoles> on the other hand, if the hotspot node is in a terrible state, one minute recovery time may be incidental
21:34:23 <acoles> sorry, on that note I need to drop, and I will miss the next couple of meetings (vacation)
21:34:24 <timburke_> the assumption is that it'll be a more noticeable effect on smaller clusters, yeah? as the number of proxies grows, the chance that a client will get routed to a proxy that's currently error-limiting the hotspot should go down?
21:34:40 <acoles> ^^ yes
21:34:40 <timburke_> all right -- have a good holiday, acoles!
21:34:48 <acoles> :wave
21:34:55 <acoles> 👋
21:34:59 <kota> enjoy acoles
21:35:05 <acoles> thank you
21:35:29 <timburke_> maybe i'll get some load testing done in my saio or home lab while you're out :-D
21:35:44 <timburke_> #topic s3api test suite
21:36:21 <timburke_> nothing new to report here; i think it should be ready
21:37:00 <zaitcev> cool
21:37:14 <timburke_> since it's just adding more tests that already pass, i'm inclined to self-approve if i don't hear anything by, say, next week
21:38:13 <timburke_> that's all i've got
21:38:19 <timburke_> #topic open discussion
21:38:25 <timburke_> anything else we should bring up this week?
21:40:13 <timburke_> all right, i'm calling it
21:40:22 <zaitcev> Next PTG is in person, I heard.
21:40:25 <timburke_> thank you all for coming, and thank you for working on swift!
21:40:29 <timburke_> oh, yes!
21:40:36 <kota> oh really
21:40:39 <timburke_> in Columbus, OH
21:40:57 <timburke_> #link https://openinfra.dev/ptg
21:41:08 <timburke_> Oct 17-20
21:42:05 <timburke_> all right, one more time :-)
21:42:08 <timburke_> thank you all for coming, and thank you for working on swift!
21:42:13 <timburke_> #endmeeting