21:00:17 <timburke> #startmeeting swift
21:00:17 <opendevmeet> Meeting started Wed Sep 13 21:00:17 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:17 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:17 <opendevmeet> The meeting name has been set to 'swift'
21:00:24 <timburke> who's here for the swift meeting?
21:04:23 <timburke> after standing y'all up last week, fair enough ;-)
21:04:31 <timburke> sorry about that, i was head-down trying to translate some C to python and lost track of time
21:05:16 <timburke> there were just a few things i wanted to call out this week:
21:05:26 <timburke> #topic vPTG
21:05:58 <timburke> if you haven't already, please register at https://ptg2023.openinfra.dev/ -- the PTG will take place Oct 23-27
21:06:51 <timburke> i still haven't seen any finalized slots for meeting times, but i might just put together a doodle poll for meeting times based on prior vPTGs for next week
21:07:08 <timburke> please add topics to the etherpad at https://etherpad.opendev.org/p/swift-ptg-caracal
21:07:49 <timburke> #topic server side copy and sysmeta
21:09:12 <timburke> clayg, acoles, and i have been thinking more about whether it makes sense to have the copy middleware copy sysmeta -- clayg has written up https://review.opendev.org/c/openstack/swift/+/894830 to try removing it
21:10:37 <seongsoocho> o/
21:11:15 <timburke> this came up in the context of an slo refactor (https://review.opendev.org/c/openstack/swift/+/893578) which had some ceph-tests failures
21:11:45 <timburke> which in turn were traced back to s3api writing down some empty sysmeta: https://github.com/openstack/swift/blob/master/swift/common/middleware/s3api/controllers/multi_upload.py#L228-L236
21:13:35 <timburke> it's one of those sorts of problems where once you start poking at it a little, it keeps getting stranger the more you investigate :-/
21:16:22 <timburke> among the take-aways: s3api shouldn't be intentionally writing empty metadata values like that; s3api and slo need to continue tolerating the empty values (as there are almost certainly objects on disk that have them); and copy's current sysmeta behavior is likely just a result of how it used to be a part of the proxy-server app
21:17:23 <timburke> if anyone can think of a reason that we *should* continue copying sysmeta as part of server-side copy, please comment on https://review.opendev.org/c/openstack/swift/+/894830
21:18:05 <timburke> and last
21:18:15 <timburke> #topic diskfile and file extensions
21:19:38 <timburke> as part of making fallocate_reserve work (at least to some degree) with chunked puts, i found myself wanting to have more context about whether this was part of a PUT, POST, or DELETE request down in diskfile
21:21:09 <timburke> at first, i thought i'd be able to just look at self._extension, but we currently update the extension *after* we've `open`ed the diskfile: https://github.com/openstack/swift/blob/2.32.0/swift/obj/diskfile.py#L3022-L3024
21:21:54 <timburke> so i took a stab at plumbing it in as a keyword arg at https://review.opendev.org/c/openstack/swift/+/894820
21:24:18 <timburke> and it's reminded us of just how ill-defined our diskfile API is -- as clayg put it, "essentially the only guidance we have is duck typing - whatever the object server asks it to do is what a working df interface has to support. Everything else that it does is just internal details."
21:25:28 <timburke> so, that might be another conversation to wade into if anyone's interested
21:25:57 <timburke> that's all i've got
21:26:08 <timburke> #topic open discussion
21:26:26 <seongsoocho> I have one topic on Open discussion.
21:26:32 <seongsoocho> https://bugs.launchpad.net/swift/+bug/2034054
21:26:51 <seongsoocho> My mentee and I are proposing to add hostname to the information that only comes out as ip in swift recon, add hostname to the response header in the recon middleware, and show it in the cli.
21:27:16 <seongsoocho> The reason I'm suggesting this is because I check the cluster status with recon, and sometimes it's hard to tell which host is which just by looking at the IP, so I thought it would be nice to add the hostname as well.
21:27:45 <timburke> oh yes, i saw that! https://review.opendev.org/c/openstack/swift/+/893583
21:27:50 <seongsoocho> Initially we were going to show it only if the human readable option is put in by the user, but I think it's okay to show it as a default option.
21:28:27 <seongsoocho> We're still working on the patch, but wanted to get your thoughts on adding hostname.
21:30:00 <timburke> seems reasonable to me -- i could go either way on whether it should be gated on the human-readable option
21:30:52 <timburke> don't forget to consider what happens when the lookup fails -- pretty sure getfqdn will return the ip address again
21:32:19 <seongsoocho> okay. I will.  probably be able to upload a patch in the next week or so.
21:32:33 <seongsoocho> I will ask for a review after
21:32:45 <timburke> oh, i see now that's covered in tests -- though i'm not sure i like the "10.1.1.2(10.1.1.2:6210)" output
21:33:15 <timburke> can do! thanks for working with the mentees, seongsoocho! always nice to have more contributors around :-)
21:33:29 <seongsoocho> :-)
21:35:42 <timburke> all right, i'll let you get on with your morning
21:35:54 <timburke> thanks for coming, and thank you for working on swift!
21:35:57 <timburke> #endmeeting