21:00:13 #startmeeting swift 21:00:13 Meeting started Wed Sep 20 21:00:13 2023 UTC and is due to finish in 60 minutes. The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:13 The meeting name has been set to 'swift' 21:00:26 who's here for the swift team meeting? 21:00:40 o/ 21:02:58 i failed to update the agenda, so i'm gonna kinda wing it ;-) 21:03:04 #topic vPTG 21:03:14 it's only about a month away now! 21:03:23 nice 21:03:24 Oct 23-27 21:03:35 i just created a poll for meeting times 21:03:44 #link https://framadate.org/liKzqQw5lZQW8Pvf 21:04:00 (thanks for the framadate suggestion, clarkb!) 21:04:40 the etherpad for topics is still rather empty, though 21:04:43 #link https://etherpad.opendev.org/p/swift-ptg-caracal 21:05:14 i'll aim to add a few topics i'm interested in after this meeting 21:06:15 if you haven't already, don't forget to register 21:06:18 #link https://ptg2023.openinfra.dev/ 21:06:48 i understand it helps the foundation track things 21:08:24 next up 21:08:42 #topic labeled metrics 21:09:18 i finally got around to rebasing my main patch for this 21:09:24 #link https://review.opendev.org/c/openstack/swift/+/885321 21:10:13 and got a vagrant-swift-all-in-one patch together to add something approaching a "real" metrics pipeline 21:10:37 #link https://github.com/NVIDIA/vagrant-swift-all-in-one/pull/150 21:10:57 i see, it's sort of prometheus exporters. 21:12:09 yup! it's similar to what we're running in prod (which explains some of the warts in the statsd mapping file) 21:12:22 nice work 21:14:35 one handy thing about statsd_exporter, though, is that it already supports some statsd extensions add labeling; my hope is that i can come up with a patch that will let you switch to emitting one of the various extensions without any gap in your graphs (if you were already using some statsd_exporter-based metrics pipeline) 21:15:45 at some point i want to include an upstream docs patch similar to what we did for adding a replication network to your SAIO (see https://docs.openstack.org/swift/latest/replication_network.html) 21:16:08 +1 21:16:28 but i might wait on that until after i've got a firmer plan on that migration path 21:18:13 i'd love for us to express more of an opinion about a recommended metrics pipeline upstream 21:19:59 thinking about stats more has led me to write a couple patches already (and surely will lead to more down the line :-) 21:20:18 #topic swift-recon-cron 21:20:56 one of them was to emit a gauge for how many asyncs are on disk 21:21:12 #link https://review.opendev.org/c/openstack/swift/+/895737 21:23:23 i see this as having two benefits over the existing recon drop: first, it's a little more timely (since it's not waiting for whatever other process to go read recon); second, it offers these stats per-disk (the distribution across disks may have gotten lumpy if a disk was unmounted for some time) 21:25:33 it got me thinking more about swift-recon-cron, though, and wondering why we have it as a separate cron-based task 21:28:17 i might try out having swift-object-updater (or maybe swift-object-server? like, the worker-management process) spin out a separate thread/process to handle swift-recon-cron's job, and have the scheduling go in that config 21:29:32 that's surely going to warrant some discussion, so it's one of the topics i should add to the etherpad :-) 21:30:09 #topic error-limiting stats 21:30:13 the other patch was 21:30:16 #link https://review.opendev.org/c/openstack/swift/+/895976 21:30:45 which would add a counter for when we actually skip a node in NodeIter because of error limiting 21:31:14 this was in part me trying to figure out how to assess one of acoles's changes 21:31:31 #link https://review.opendev.org/c/openstack/swift/+/895976 21:31:41 #undo 21:31:41 Removing item from minutes: #link https://review.opendev.org/c/openstack/swift/+/895976 21:31:44 #link https://review.opendev.org/c/openstack/swift/+/890527 21:31:51 that's the one 21:32:42 where he's making sure that we're incrementing errors for a node even if we can't find a replacement 21:33:21 it looks like what Pete discussed a few weeks ago. 21:35:00 possibly -- all the more reason for us to want to get better metrics/logging around it :-) 21:35:12 :) 21:37:05 that's at the head of a chain of to unify _get_next_response_part in the proxy for replicated and EC 21:37:26 #link https://review.opendev.org/c/openstack/swift/+/890919 21:38:46 next up 21:39:08 #topic part-number queries for slo/MPU 21:40:13 indianwhocodes has rebased his patches on top of some of clayg's refactors -- we're getting a decently-long chain now 21:40:28 #link https://review.opendev.org/c/openstack/swift/+/894800 21:41:07 has s3api ignore some MPU-specific sysmeta if the object isn't an slo 21:41:20 #link https://review.opendev.org/c/openstack/swift/+/893578 21:42:33 refactors slo a good bit, but (shouldn't) result in any behavioral change 21:42:49 #link https://review.opendev.org/c/openstack/swift/+/894570 21:43:33 adds the ability to request the range corresponding to part number N from an slo 21:43:43 and finally 21:43:49 #link https://review.opendev.org/c/openstack/swift/+/894580 21:44:40 provides the (now actually documented!) partNumber support for s3api 21:44:49 see also, https://bugs.launchpad.net/swift/+bug/1735284 21:45:45 all right, i think that's most of what all's been going on this past week 21:45:50 #topic open discussion 21:45:59 anything else we ought to talk about today? 21:46:31 not from my side, thanks for proceeding 21:46:58 all right, i'll let you get on with your morning then 21:47:08 thank you for coming, and thank you for working on swift! 21:47:13 #endmeeting