21:00:38 #startmeeting swift 21:00:38 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:38 The meeting name has been set to 'swift' 21:00:46 who's here for the swift meeting? 21:00:56 hi 21:02:30 as usual, the agenda's at 21:02:34 #link https://wiki.openstack.org/wiki/Meetings/Swift 21:02:43 I'm here for a while 21:02:51 first up 21:03:01 #topic tempurl sha1 deprecation 21:03:46 so i realized we probably should have added client support before we went and removed sha1 from the server defaults 21:04:05 and i proposed https://review.opendev.org/c/openstack/python-swiftclient/+/845157 to remedy that 21:06:04 in general, i think clayg wasn't real happy with how https://review.opendev.org/c/openstack/swift/+/525771 shook out 21:06:14 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 client support first would have helped i guess 21:07:57 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 yeah, I'm not sure - were we logging warnings if sha1 was still configured after deprecation? 21:08:44 or that the feature isn't being used 21:08:46 but logging stats about clients would be cool 21:10:09 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 i see 21:11:12 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 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 if we *do* do that, how long should we wait before requiring the explicit opt-in? 21:14:23 IDK, it feels like a lot of work in lieu of ops not reading upgrade impacts 21:14:44 ;/ 21:15:12 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 hmm 21:16:02 it's an appeal to authority, but: https://www.schneier.com/essays/archives/2004/08/cryptanalysis_of_md5.html 21:16:18 as of 2004, "It’s time for us all to migrate away from SHA-1." 21:17:59 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 I'm not militant about client first. I think it's sufficient if curl can be used. 21:18:51 The shift in the defaults thanks to TripleO people being lazy is something that bothers me. 21:19:58 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 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 speaking of 21:21:45 #topic formpost digest algos 21:22:17 i think i'm happy with https://review.opendev.org/c/openstack/swift/+/838434 now 21:22:49 the formats of signatures match tempurl, and i cleaned up the tests a little 21:24:41 i think both mattoliver and i have touched it a lot -- anyone else have some review bandwidth for it? 21:25:05 otherwise, maybe we'll just get the two of us on board and call it good enough ;-) 21:25:30 sorry, I'm not going to be able to help with that for a while 21:27:38 all right, we'll sort it out -- that first patch in particular is purely additive, so i'm not too worried 21:28:31 #topic backend ratelimiting 21:29:30 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 +1 21:30:11 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 and https://review.opendev.org/c/openstack/swift/+/839088 is the follow-up to have 529 not count for error-limiting 21:31:58 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 on the other hand, if the hotspot node is in a terrible state, one minute recovery time may be incidental 21:34:23 sorry, on that note I need to drop, and I will miss the next couple of meetings (vacation) 21:34:24 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 ^^ yes 21:34:40 all right -- have a good holiday, acoles! 21:34:48 :wave 21:34:55 👋 21:34:59 enjoy acoles 21:35:05 thank you 21:35:29 maybe i'll get some load testing done in my saio or home lab while you're out :-D 21:35:44 #topic s3api test suite 21:36:21 nothing new to report here; i think it should be ready 21:37:00 cool 21:37:14 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 that's all i've got 21:38:19 #topic open discussion 21:38:25 anything else we should bring up this week? 21:40:13 all right, i'm calling it 21:40:22 Next PTG is in person, I heard. 21:40:25 thank you all for coming, and thank you for working on swift! 21:40:29 oh, yes! 21:40:36 oh really 21:40:39 in Columbus, OH 21:40:57 #link https://openinfra.dev/ptg 21:41:08 Oct 17-20 21:42:05 all right, one more time :-) 21:42:08 thank you all for coming, and thank you for working on swift! 21:42:13 #endmeeting