21:01:00 <timburke> #startmeeting swift
21:01:00 <opendevmeet> Meeting started Wed May 10 21:01:00 2023 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:00 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:00 <opendevmeet> The meeting name has been set to 'swift'
21:01:08 <timburke> who's here for the swift meeting?
21:01:14 <kota> o/
21:02:11 <mattoliver> o/
21:03:09 <timburke> i've been a bit distracted and haven't updated the agenda -- but there were a couple items from last week worth following up on
21:03:24 <timburke> #topic requests-mock pytest plugin
21:03:53 <timburke> #link https://review.opendev.org/c/openstack/swift/+/882105
21:04:40 <timburke> the patch still needs to get restacked -- nobody's touched it in a bit, but i should be able to do that this afternoon
21:05:53 <timburke> after that, i think it'll be pretty straightforward to merge the dev-env fix, then look at the probe test that wants to use s3api separately
21:06:16 <timburke> #topic non-ascii py2 metadata from py3
21:06:21 <timburke> #link https://review.opendev.org/c/openstack/swift/+/878558
21:06:46 <timburke> clayg already has a +2 on it, and mattoliver has started to take a look
21:07:17 <mattoliver> yeah, it looks good, some great research went into it, thanks Tim.
21:07:39 <mattoliver> Just want to test it in my SAIO on some different py2/py3 just to make sure
21:08:21 <timburke> mattoliver, you're right that the key to it all is that we can (for now, anyway) determine that meta was written by py2 vs py3 by looking for some magic string in the raw meta
21:09:00 <mattoliver> kk, nice find on a unique magic string to use.
21:09:31 <timburke> i still need to get a follow-up written that would have us *not* need to rely on that going forward -- but getting all existing meta readable had to come first
21:09:44 <mattoliver> yeah +1
21:10:40 <mattoliver> always returning a native string or something (like you suggested in the change) does make alot of sense.
21:11:30 <timburke> i'm not sure *when* i'll get to the follow-up, though, which maybe isn't great
21:12:33 <timburke> in part that's because i still need to revisit...
21:12:37 <timburke> #topic ring v2
21:12:53 <mattoliver> that's ok. like you said, lets get the data out now
21:13:27 <timburke> clayg has started poking at the patch some more, and noticed that it needs some work around composite rings
21:14:02 <mattoliver> around the dev_id side wasn't it
21:14:07 <mattoliver> *size
21:14:23 <timburke> (i actually knew about that, once upon a time, but forgot about it as the patch to focus on has changed a few times)
21:15:09 <mattoliver> makes sense, it has gone through many iterations
21:15:46 <timburke> yes -- basically, if you had two builders which independently had dev ids that would fit in 1 byte (say), but together needed wider arrays, it'd blow up (i think with an OverflowError? probably)
21:16:40 <mattoliver> so me need to take the new created device ids into account when creating the composit ring.
21:17:00 <mattoliver> have you started working on it, or would you like me to have a go?
21:17:10 <mattoliver> (depending on how busy you are)
21:17:36 <timburke> i haven't started on it, but i think i can get that fixed up this week, and also squash down a follow-up i had to try to draw better lines on the ZlibReader api
21:17:44 <timburke> thanks though, mattoliver :-)
21:18:01 <mattoliver> kk, let me know when you want me to take a  look at the patch then :)
21:18:03 <mattoliver> nps
21:18:37 <timburke> next up...
21:18:50 <timburke> #topic CMU student summer project
21:19:50 <timburke> diablo_rojo came to me recently about putting together a mentorship project for "a group of 4-5 students from mid may to mid august"
21:20:12 <mattoliver> oh cool
21:20:17 <timburke> i'm not sure off-hand what that good project would *be*, though...
21:20:19 <kota> nice
21:21:26 <timburke> there are some brief write-ups for some other projects at https://etherpad.opendev.org/p/CM-project-proposals
21:21:36 <mattoliver> health status command that takes in a bunch of data (recon, dispersion, ring dispersion etc)?
21:21:50 <zaitcev> ProxyFS :-)
21:21:57 <mattoliver> lol
21:22:48 <mattoliver> anyway, nice, will do some brain storming
21:23:10 <timburke> thanks -- and if anyone's interested in being one of the mentors, let me know!
21:23:53 <timburke> the health-status idea's not bad -- though it might be tricky to sort out what should and shouldn't be included :-/
21:24:27 <mattoliver> thats apart of the project ;)
21:25:02 <mattoliver> I'm happy to put my hand up as a mentor, although my timezone doesn't usually help
21:25:11 <timburke> but if they have to start from there, it may require more than 3 months to figure out ;-)
21:25:32 <mattoliver> true
21:25:37 <timburke> that's all i've got
21:25:43 <timburke> #topic open discussion
21:25:57 <timburke> anything else we should bring up this week?
21:26:09 <zaitcev> Are you guys overloading Alistair recently? I want my dark data watcher complete dammit.
21:26:21 <zaitcev> It's even your patch, Tim.
21:26:28 <mattoliver> lol
21:26:46 <timburke> you're right, i should look at that again... sorry
21:26:53 <mattoliver> Al has been away for the last week or 2. Just got back this week. I'll remind him ;)
21:27:21 <zaitcev> https://review.opendev.org/c/openstack/swift/+/787656
21:27:31 <zaitcev> Also
21:27:43 <zaitcev> On a completely unrelated note, I'm going to Vancouver.
21:29:06 <mattoliver> Lucky
21:29:16 <kota> oh great, but not me unfortunately.
21:29:30 <timburke> oh, cool! i'm not planning on going, but i know notmyname will be there :-)
21:29:50 <mattoliver> my employer isn't letting people travel yet, and the cost to pay my own way probably is a little too high from Oz.
21:30:09 <mattoliver> For me, it's same old. Got even more tracing unit tests done. Been testing some of jianjain's new sharder metrics.
21:30:57 <mattoliver> Also after shardrange listing_v2 in memcache landed it's make my internal client get shard ranges interface more problematic.. so disucssions happening there on the best follow up approach.
21:31:09 <mattoliver> *made
21:31:48 <mattoliver> #link https://review.opendev.org/c/openstack/swift/+/877584
21:32:06 <mattoliver> I do have a random follow up as a possible solution.
21:33:05 <mattoliver> long term having more internal clients around in the cluster can be a little expensive, ie they load up all the rings. Al and I discussed a possible future idea of having the internal client lazy load the rings, so we only load what we end up using.
21:33:27 <mattoliver> so for the sharder, it'll only ever load up the container ring, because that's all it uses.
21:34:04 <mattoliver> thats a little of topic from my patch but was an interesting memory saving thought
21:35:05 <timburke> oh man, i should dust off https://review.opendev.org/c/openstack/swift/+/670674 again -- it's been a couple years since i last looked at it...
21:35:35 <timburke> but i'd love to make it so we aren't so worried about ring loading ;-)
21:36:01 <mattoliver> yeah! that would work too!
21:36:43 <mattoliver> A local service over a domain socket.. maybe its another idea for a group project?
21:37:04 <timburke> 💡
21:37:07 <zaitcev> A local service to do what? Ring lookups?
21:37:11 <timburke> yup
21:39:42 <mattoliver> anyway, that's all I've got
21:40:12 <timburke> alright, i think i'll call it then
21:40:24 <timburke> thank you all for coming, and thank you for working on swift!
21:40:28 <timburke> #endmeeting