| opendevreview | Alistair Coles proposed openstack/swift master: Add more unit tests for ranged GETs https://review.opendev.org/c/openstack/swift/+/888229 | 11:10 |
|---|---|---|
| opendevreview | Alistair Coles proposed openstack/swift master: WIP: container-server: do [end_]marker filtering in sql query https://review.opendev.org/c/openstack/swift/+/888310 | 17:35 |
| opendevreview | Merged openstack/pyeclib master: Test under py311 https://review.opendev.org/c/openstack/pyeclib/+/888175 | 17:59 |
| kota | good morning | 20:55 |
| timburke | kota, o/ | 20:57 |
| kota | timburke: o/ | 20:58 |
| timburke | #startmeeting swift | 21:00 |
| opendevmeet | Meeting started Wed Jul 12 21:00:20 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 21:00 |
| opendevmeet | The meeting name has been set to 'swift' | 21:00 |
| timburke | who's here for the swift team meeting? | 21:00 |
| kota | hi | 21:00 |
| mattoliver | o/ | 21:01 |
| timburke | i actually update the agenda! though there's surely some stuff i missed :P | 21:01 |
| timburke | #link https://wiki.openstack.org/wiki/Meetings/Swift | 21:01 |
| timburke | first up | 21:01 |
| timburke | #topic ssync metadata corruption | 21:02 |
| timburke | #link https://bugs.launchpad.net/swift/+bug/2020667 | 21:02 |
| timburke | the fix merged! | 21:02 |
| mattoliver | yay | 21:03 |
| kota | great | 21:03 |
| timburke | i figure that's as good a spot as any to cut a new release -- it's been something like 3 months since our last one | 21:03 |
| timburke | so i'll work on getting some release notes up this week | 21:03 |
| mattoliver | yeah, good idea | 21:03 |
| timburke | #topic logging/metrics for backend HEAD requests on cache misses | 21:04 |
| timburke | #link https://review.opendev.org/c/openstack/swift/+/884931 | 21:05 |
| timburke | it's gotten some positive feedback, but it looks like acoles still has some hesitations | 21:05 |
| timburke | meanwhile, we've got other patches starting to build on it | 21:06 |
| timburke | #link https://review.opendev.org/c/openstack/swift/+/885798 | 21:06 |
| mattoliver | oh a logged app intersting idea | 21:07 |
| timburke | i know i previously suggested it maybe ought to have an upstream bug -- i might still try to write that | 21:07 |
| mattoliver | yeah sucks that we lost those metrics cool | 21:07 |
| timburke | i suppose one question is whether we want to prioritize getting that landed ahead of the next release, too | 21:08 |
| timburke | i think we've only had the one release where we dropped the metrics | 21:08 |
| indianwhocodes | o/ | 21:09 |
| timburke | if so, i *definitely* ought to write up that launchpad bug | 21:09 |
| mattoliver | yeah, write up the bug. I'll give this a review and lets try and get it landed before the end of the week | 21:11 |
| mattoliver | so it can be in the release | 21:11 |
| timburke | thanks | 21:11 |
| timburke | #topic partNumber support for s3api | 21:12 |
| timburke | #link https://bugs.launchpad.net/swift/+bug/1735284 | 21:12 |
| timburke | it sounds like indianwhocodes is going to take a look at implementing this soon! | 21:12 |
| indianwhocodes | yes its a priority! | 21:12 |
| mattoliver | cool | 21:13 |
| timburke | for some background: there's a parameter you can provide to GET/HEAD requests against AWS that will fetch individual parts of a multipart object | 21:14 |
| timburke | we don't currently support it -- and not in a "we'll just ignore it" sort of a way -- we'll respond with a 405 | 21:14 |
| kota | nice | 21:14 |
| kota | nice to have, i mean | 21:15 |
| timburke | for a while it was undocumented, but at least one of AWS's SDKs would use it; a few years ago it got some documentation | 21:15 |
| mattoliver | OK, so whats the plan, give partnumber support (or something like it) to SLO and then plumb that support in s3api | 21:17 |
| timburke | but what's really driving the prioritization is that we want to provide some means of verifying MPU downloads to clients. one way we can do that is to let clients download individual parts, calculate the MD5s of each part as it's downloaded, then calculate the MD5-of-MD5s to compare against the ETag for the MPU | 21:17 |
| mattoliver | cause it also sounds nice for SLOs | 21:17 |
| mattoliver | The bug talks about being able to do it for normal objects too, so how will that work? does it turn it into a byte request? or do we ignore non slos? | 21:19 |
| timburke | mattoliver, yeah, exactly. it's a little debatable how much utility you get for SLOs, since the client could also just download the actual manifest, then grab the segments directly -- but it definitely seems like a way to make it easier to write a better client without going all the way to relying on a bunch of swift-isms | 21:19 |
| mattoliver | in a normal object would it be 1/1000s of the object (or whatever the max partnumber was) | 21:20 |
| mattoliver | so an auto calculated ranged request | 21:20 |
| mattoliver | Sorry just thinking out loud now | 21:21 |
| timburke | i think the thing to do would be to use a query param, like S3 does -- object-server doesn't even see the thing, so it'd automatically send back everything. then slo can look at the query param, see that it got a manifest as a response, and send back just the one segment. if it *wasn't* a manifest, again, we'll just send what we *did* get back | 21:22 |
| mattoliver | kk | 21:22 |
| timburke | other things going on... | 21:22 |
| timburke | #topic container server performance | 21:23 |
| timburke | jian jian has been doing some profiling, and noticed a lot of CPU time being spent on getting shard ranges | 21:23 |
| timburke | it looks like he and acoles will be seeing how we can avoid unnecessary work and improve the container server | 21:25 |
| timburke | mostly, this has been coming out of observations about much lower than expected performance, partitularly for container with large numbers of shards (think 10-20,000) | 21:26 |
| timburke | ok, a more administrative note | 21:27 |
| timburke | #topic next meeting | 21:27 |
| mattoliver | yeah, when we were writing sharding we thought about large number of shards, but it was so far off I think we punted it. Well I guess were here now | 21:27 |
| zaitcev | I don't get that partNumber thing... Why does Range: not work for those guys. | 21:27 |
| timburke | #undo | 21:28 |
| opendevmeet | Removing item from minutes: #topic next meeting | 21:28 |
| mattoliver | probably could start having high water marks when syncing shards now that we're getting > 10k | 21:28 |
| zaitcev | Actually n/m. It is what it is and we ought to be compatible. | 21:28 |
| timburke | zaitcev, the main trouble is that the client doesn't know what the original sizes were for uploads -- so it doesn't know how to build the MD5-of-MD5s | 21:29 |
| mattoliver | currently we always send them all on every container replication. So yeah there is a bunch of more to make sharding work better with alot more shards. | 21:29 |
| timburke | (s3's way of doing it is almost but not quite the same as SLO's; it's good enough to think of how you would go about verifying an SLO download if you knew it was an SLO, but didn't have access to the actual manifest) | 21:30 |
| zaitcev | ok | 21:31 |
| timburke | like, range requests are good enough to get you parallel downloading, but you can't try to recreate the etag you got back unless you know the individual part sizes | 21:32 |
| timburke | #topic next meeting | 21:33 |
| timburke | i'm going to be out on vacation for a couple of weeks | 21:33 |
| timburke | so i'm going to propose that we skip the next couple meetings, and come back Aug 2 | 21:34 |
| indianwhocodes | sounds good | 21:34 |
| timburke | unless anyone else would like to volunteer to chair the meeting | 21:34 |
| mattoliver | I'm happy to chair while your gone.. but also only if there is something to talk about.. so happy to skip. | 21:35 |
| mattoliver | so skipping is fine. | 21:35 |
| timburke | all right, then -- if anyone has anything they'd like to bring up, add it to the agenda and mattoliver will keep an eye out for it ;-) | 21:36 |
| timburke | otherwise, we'll next meet up in August | 21:36 |
| timburke | that's all i've got | 21:36 |
| timburke | #topic open discussion | 21:36 |
| timburke | anything else we ought to bring up? | 21:36 |
| mattoliver | kk | 21:36 |
| zaitcev | I'm going on vacation too, to Wisconsin. | 21:37 |
| kota | i saw the nest ptg info in my mailbox... | 21:37 |
| timburke | oh, nice! i spent a few years there -- where you going, zaitcev? | 21:37 |
| kota | next | 21:37 |
| mattoliver | oh yeah, I keep forgetting its summer time in the US. | 21:37 |
| zaitcev | timburke: https://www.eaa.org/en/airventure | 21:37 |
| timburke | oh, yeah! i heard something about the PTG... | 21:37 |
| mattoliver | kota: yeah I saw that too! a virtual one | 21:38 |
| timburke | zaitcev, looks exciting :-) | 21:38 |
| kota | https://ptg2023.openinfra.dev/ | 21:38 |
| mattoliver | End of October | 21:38 |
| zaitcev | So, next PTG is virtual again. | 21:38 |
| mattoliver | looks like it. | 21:39 |
| mattoliver | not sure if their alternating or reverting back to it. | 21:39 |
| zaitcev | So, is there anything I can do to make acoles to review https://review.opendev.org/c/openstack/swift/+/787656 | 21:40 |
| zaitcev | Maybe I can review something...? But looks like you guys do well without me. | 21:40 |
| mattoliver | acoles was away on vacation last week. I'll poke him about it for you if you like zaitcev | 21:41 |
| timburke | we always appreciate more eyes :-) i'll try to take a look -- i'm long overdue to check it out again | 21:41 |
| mattoliver | +1 | 21:41 |
| zaitcev | Technically it's your patch :-) | 21:41 |
| timburke | all right, i think i'll call it | 21:44 |
| timburke | thank you all for coming, and thank you for working on swift! | 21:45 |
| timburke | #endmeeting | 21:45 |
| opendevmeet | Meeting ended Wed Jul 12 21:45:05 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:45 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/swift/2023/swift.2023-07-12-21.00.html | 21:45 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/swift/2023/swift.2023-07-12-21.00.txt | 21:45 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/swift/2023/swift.2023-07-12-21.00.log.html | 21:45 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!