21:00:12 <timburke> #startmeeting swift
21:00:12 <opendevmeet> Meeting started Wed Mar 16 21:00:12 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:12 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:12 <opendevmeet> The meeting name has been set to 'swift'
21:00:22 <timburke> who's here for the swift meeting?
21:00:39 <acoles> o/
21:01:07 <mattoliver> o/
21:02:11 <timburke> as usual, the agenda's at https://wiki.openstack.org/wiki/Meetings/Swift
21:02:38 <timburke> first up
21:02:41 <timburke> #topic ptg
21:03:05 <timburke> i signed up for meeting times, though i haven't put them on the etherpad yet. will do that shortly
21:04:11 <timburke> all 1300-1700 UTC (sorry mattoliver, you can definitely bail early ;-)
21:04:12 <mattoliver> kk
21:05:04 <mattoliver> Will just try and be a night owl that week
21:05:56 <acoles> I feel bad for Matt
21:06:08 <timburke> speaking of the etherpad, thanks for adding topics! we should have a good bit to talk about :-)
21:07:20 <timburke> if you haven't already, please register (i realized late last week that i still hadn't)
21:07:22 <timburke> #link https://openinfra-ptg.eventbrite.com/
21:08:03 <timburke> that's all i've got for the ptg
21:08:12 <timburke> #topic 2.29.1 release
21:08:39 <timburke> i still want to get one more release out, and i think my deadline's this week
21:09:01 <timburke> it's smaller than the last couple releases, but i think that
21:09:06 <timburke> 's a good thing :-)
21:09:27 <timburke> if you have a chance, please look over the changelog
21:09:30 <timburke> #link https://review.opendev.org/c/openstack/swift/+/833718
21:09:44 <mattoliver> Not swift release related, but I did push up a patch yesterday to add formpost sig generation support to swiftclient.
21:09:56 <mattoliver> but I guess its too late to do another swiftclient release
21:10:18 <mattoliver> cause then we can wait a cycle and remove the formpost tool from swift (if we squeezed it in)
21:10:38 <timburke> yeah, unfortunately, the client deadline passed a bit ago
21:10:52 <mattoliver> oh well. next time then, I guess no rush
21:11:20 <timburke> the big reason i want one more server release is that top item: "This is the final stable branch that will support Python 2.7."
21:11:36 <timburke> want to make sure we're broadcasting that loud and clear :-)
21:11:58 <mattoliver> yeah +1, thats important.
21:12:05 <timburke> next up
21:12:16 <timburke> #topic drop py2 from swiftclient
21:12:36 <timburke> are there any objections to getting moving on that, like, *now*?
21:13:32 <timburke> there's a change i wanted to approve, but it touches requirements, and we've got a py2-only requirement that's keeping the requirements-check job from passing
21:13:37 <acoles> timburke: did you want to get the SHA1 deprecation in this release https://review.opendev.org/c/openstack/swift/+/525771 ?
21:14:10 <timburke> *shrug* either way. it's sat around *this* long...
21:14:22 <acoles> maybe the swiftclient side needs fixing first anyway
21:14:33 <acoles> so, yeah, defer
21:14:42 <timburke> good point
21:16:08 <timburke> since we've already got the stable/yoga branch cut for swiftclient, it seems like dropping py2 ought to be ok
21:18:00 <timburke> well, i'm not hearing any objections, anyway ;-)
21:18:11 <timburke> #topic safer WSGI server reloads
21:19:06 <timburke> i was playing with our SIGUSR1 handling, and generally, it's pretty great: server reloads, and clients never notice
21:19:48 <timburke> sometimes, though, it all goes terribly: server re-exec's, then immediately dies, and client traffic stops
21:20:52 <acoles> :(
21:20:58 <timburke> this can happen if, say, you accidentally write out a config that's invalid. or if you're trying to switch between py2 and py3, but not all your proxy middlewares are installed for py3
21:21:20 <timburke> so i put together a couple changes
21:21:24 <timburke> #link https://review.opendev.org/c/openstack/swift/+/833124
21:22:27 <timburke> adds a --check-config option to all the WSGI servers -- they'll go through all the normal set-up stuff right up to the point of opening sockets
21:23:08 <mattoliver> oh nice
21:23:09 <timburke> with that, you can verify the config before sending the reload signal
21:23:44 <timburke> if you want to use it in a systemd unit, though, the ExecReload gets a little hairy
21:23:58 <timburke> #link https://review.opendev.org/c/openstack/swift/+/833174
21:24:24 <timburke> tries to make that a good bit better by introducing a new swift-reload command
21:24:48 <timburke> it'll handle the config check, sending the signal, and waiting for the reload to complete
21:25:34 <timburke> so by the time it terminates, the clients should only be able to connect to servers running the new config
21:26:10 <timburke> that second one still needs a boatload of tests, though
21:26:13 <mattoliver> what happens is the config is wrong, errors and leaves the old servers still running?
21:26:54 <timburke> yup -- swift-reload exits non-zero and doesn't send any signal
21:27:17 <mattoliver> assumed so, but just wanted to confirm :)
21:27:40 <mattoliver> this is really cool!
21:28:22 <timburke> next cool thing for me to hack on would be making more use of the systemd notify socket :-)
21:28:42 <timburke> that's all i've got
21:28:48 <timburke> #topic open discussion
21:28:55 <timburke> what else should we talk about this week?
21:29:41 <mattoliver> I dont have too much, I dumped it all into the PTG etherpad :P
21:30:08 <mattoliver> I made a follow up sha1 deprecation of formpost
21:30:35 <mattoliver> but to make it work I had to give formpost some extra love too. Can't deprecate sha1 when it only supported sha1 :P
21:30:57 <mattoliver> Which is what snowballed into creating a swiftclient subcommand for formpost
21:31:24 <mattoliver> #link https://review.opendev.org/c/openstack/swift/+/833713
21:31:30 <timburke> thanks for all that :-) i had this feeling like there might be some scope creep
21:31:55 <mattoliver> #link https://review.opendev.org/c/openstack/python-swiftclient/+/833954
21:33:26 <mattoliver> The first deprecates sha1, but for the moment still allows it (don't have to specify in config) but if you do you'll get deprecation warnings in log. So slightly different then tempurls.
21:36:01 <mattoliver> Anyway, just a heads up.
21:36:39 <timburke> how do we feel about the approach i took for tempurl? should i continue to allow sha1 by default but log a warning? i think i'd considered it, but backed off when i thought about how it would encourage ops to explicitly set the allowed_digests (to quiet the warning) which might cause pain later if we ever wanted to drop sha256, say
21:37:28 <mattoliver> I think for tempurl it's ok. we've supported other digests for ages, so they have to opt in.
21:37:47 <timburke> it seemed like "more secure by default" was fairly defensible stance to take -- but in the extreme, like we'd have for formpost, i'm not sure it holds up
21:38:17 <mattoliver> formpost they haven't had a chance yet, so wanted to make sure it's still all ok. although I did change the default to sha512, so lazy people will migrate by default ;)
21:38:51 <timburke> mattoliver, still a question of how long *clients* have supported sha256 tempruls, though :-/
21:40:07 <timburke> well, as long as we're planning on both these things moving forward in the next cycle, i suppose we could wait to hash it out until the PTG :P
21:40:18 <mattoliver> true :)
21:41:48 <timburke> all right, i'm'a call it and let acoles get to bed :-)
21:41:58 <mattoliver> kk :)
21:41:59 <timburke> thank you for coming, and thank you for working on swift!
21:42:03 <timburke> #endmeeting