| acoles | anyone around for the 0700 meeting? | 07:02 |
|---|---|---|
| cschwede | o/ | 07:02 |
| kota_ | hi | 07:02 |
| acoles | cschwede: let's wait to see if mattoliver is around | 07:03 |
| acoles | kota_: hi! | 07:03 |
| kota_ | acoles: o/ | 07:03 |
| mattoliver | oh yeah, I forgot! | 07:04 |
| mattoliver | hold on :) | 07:05 |
| mattoliver | I was reviewing ringv2 (again) and lost down rabbit holes. So didn't even get the agenda ready. But let's have a quick off the cuff meeting :) | 07:05 |
| mattoliver | #startmeeting swift | 07:06 |
| opendevmeet | Meeting started Wed Jul 30 07:06:02 2025 UTC and is due to finish in 60 minutes. The chair is mattoliver. Information about MeetBot at http://wiki.debian.org/MeetBot. | 07:06 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 07:06 |
| opendevmeet | The meeting name has been set to 'swift' | 07:06 |
| mattoliver | Agenda as always (which is currently not updated) is at: | 07:06 |
| mattoliver | #link https://wiki.openstack.org/wiki/Meetings/Swift | 07:06 |
| mattoliver | #topic Bug triage | 07:06 |
| mattoliver | cschwede: sorry to keep probing you on this every 2 weeks :P | 07:07 |
| mattoliver | It's alot of work and I think last time we talked about slowing down if you need to catch your breath (and we all should be helping you). | 07:07 |
| cschwede | No problem :) No updated bugs this time, but was wondering if we need a different approach at all. Eg. closing bugs > X years old or sth similar. | 07:08 |
| cschwede | Quite a few bugs need a good amount of time to check if they are still valid | 07:08 |
| mattoliver | oh maybe :hmm: | 07:09 |
| mattoliver | Nice project for any new swift devs who want to get their swift feet wet. | 07:09 |
| cschwede | I mean - if they are open for eg 5+ years, they are likely not important at all? | 07:09 |
| mattoliver | ie, checking bugs. | 07:09 |
| mattoliver | lol, true | 07:10 |
| mattoliver | maybe we should get some metrics on our bugs. I mean maybe even 10years would get rid of alot :P | 07:10 |
| cschwede | We don't want to scare new devs immediately away, do we? ;) | 07:10 |
| cschwede | Indeed. Maybe we simply start with a generous time (5/10 years), close them and have a look at the impact. | 07:11 |
| mattoliver | True. I know when I've picked bugs for newbies to work on, I somestimes start with "maybe check if its still valid". But telling them to go check all bugs would be too much | 07:11 |
| mattoliver | Yeah +1 | 07:12 |
| acoles | is it easy to list the bugs filtered by age? perhaps we should try to at least scan the subject lines in case there are any that are obviously still valid? | 07:13 |
| mattoliver | I'll let timburke__ and others who'll async have a say too. But I think it sounds reasonable. | 07:13 |
| acoles | I'm thinking more of the bugs that are written more as a wish for future enhancement than an immediate code problem | 07:14 |
| mattoliver | yeah, some of the low hanging fruit "feature requests" like bugs are still nice to have. | 07:14 |
| cschwede | Maybe exclude wishlist bugs then? Quickly looking at the oldest bugs: https://bugs.launchpad.net/swift/+bugs?orderby=datecreated&start=0 | 07:15 |
| mattoliver | #link https://bugs.launchpad.net/swift/+bugs?orderby=datecreated&start=0 | 07:16 |
| cschwede | Maybe it's a good topic for another PTG discussion ;) | 07:17 |
| mattoliver | kk. I think closing old bugs should be OK. But maybe a scan of the subjects at least would be useful. And yeah maybe keeping all wishlist makes sense. | 07:19 |
| acoles | how can we see a list of in-use tags? (the first is a wishlist but is it wishlist, wish_list or ...) | 07:19 |
| acoles | oh there is autocomplete for existing tags | 07:20 |
| acoles | so *is* there a wishlist tag? | 07:20 |
| mattoliver | there is things in wishlist importance | 07:21 |
| acoles | aha, thanks mattoliver | 07:21 |
| mattoliver | maybe its time to hit up the launchpad api and do some magic. | 07:21 |
| cschwede | and a "low-hanging-fruit" tag, useful for new devs | 07:22 |
| acoles | another idea might be to tag anything we look at and decide to keep with '2025' or similar, then cull anything > 5 years without '2025' | 07:22 |
| mattoliver | Let's wait to see what the timburke__ and co think. But I'll do an initial parse and try and point out (only from a very high level look) at things that we might want to save of anything older then 5years are we'll start there? | 07:22 |
| acoles | +1 | 07:23 |
| mattoliver | kk, let's move on then | 07:23 |
| mattoliver | thanks cschwede ! | 07:23 |
| mattoliver | #topic eventlet removal POC update | 07:24 |
| mattoliver | cschwede: any time to play with this yet? | 07:24 |
| acoles | some bugs impact more projects than swift but seem very stale e.g. https://bugs.launchpad.net/swift/+bug/1179009 but s | 07:24 |
| cschwede | Yes! Currently working on getting some tests passing for my object server POC. Another new deep rabbit hole! | 07:25 |
| acoles | oops sorry, we've moved on | 07:25 |
| mattoliver | lol, yup, but we're really thankful for you to at least take the initial leap :P | 07:27 |
| mattoliver | lol acoles that one is incomplete everywhere it seems and 12 years old | 07:29 |
| mattoliver | Anyway thanks again cschwede | 07:29 |
| mattoliver | Speaking of potential PTG topics... | 07:29 |
| mattoliver | #topic October vPTG | 07:30 |
| mattoliver | Just a reminder there is another PTG coming up in october. | 07:30 |
| mattoliver | Oct 27-31 | 07:30 |
| mattoliver | #link https://ptg.openinfra.org/ | 07:30 |
| mattoliver | Seeing as we already have a topic, maybe I should go make an etherpad for it so we can start gathering ideas eariler this time :) | 07:31 |
| mattoliver | that's just an info one really | 07:32 |
| mattoliver | We talked about the isa-l stuff last meeting. So probably don't have to re-hash that. | 07:32 |
| mattoliver | Might was well talk ringv2 while I'm neck deep into it. :P | 07:33 |
| mattoliver | #ringv2 | 07:33 |
| mattoliver | #topic ringv2 | 07:33 |
| mattoliver | I had a good chat to clayg this morning (my time) about the current state of the main patch. | 07:33 |
| mattoliver | #link https://review.opendev.org/c/openstack/swift/+/834261 | 07:34 |
| mattoliver | There are some refactors in how we'll maintain the ring reader/writer classes. But nothing major format wise that needs to change | 07:35 |
| mattoliver | So I think we're very close to landing what we have and leave the rest to follow ups | 07:35 |
| acoles | exciting | 07:35 |
| mattoliver | I have been working deeper in the chain to give us the old primary/history table in the ring, which I think we all want to improve reconstructor and replication smarts. | 07:37 |
| mattoliver | Anyway.. we have been running it in prod with no issues, so there are no worries with the current implementation. | 07:38 |
| mattoliver | I think that's all I have for today, sorry for not being more organised | 07:38 |
| mattoliver | so | 07:38 |
| mattoliver | #topic open discussion | 07:38 |
| mattoliver | acoles: I might have got nerdsniped on your more deterministic shard finding stuff. And testing some things out. | 07:39 |
| mattoliver | got some very basic code that I plan to test on some large containers because I want to make sure it's fast enough in regards to sqlite and hitting indexes etc. | 07:40 |
| mattoliver | not convinced either way yet.. and didn't get much of a chance to play too much today. Got distracted with ringv2 | 07:40 |
| acoles | ok, I did think of some potential flaws but it'd be interesting to see how you go. I don't think I'll find time to explore it much for a while | 07:41 |
| mattoliver | yeah, I have some flaws already, but let's see. Initial shard on a container would be the hardest, when we have defined upper and lower boundries I think it might work better. | 07:42 |
| mattoliver | Also it tends to leave with more smaller shards, so less efficient in sizing.. but maybe thats ok. So long as it picks right, I don't mind if things need to shrink (once that's working better). | 07:43 |
| mattoliver | I've got code for the initial shard being just out of chr bounds to my middle namespace function seems to work quite well. BUT I think it'll come down to IO speed of sqlite to be honest to see how feasible it all is. | 07:44 |
| mattoliver | Anyway, that's all I got | 07:45 |
| mattoliver | cschwede: I did see you found an account_quite recurrsion error, nice and scary find :P | 07:46 |
| mattoliver | #link https://review.opendev.org/c/openstack/swift/+/955866 | 07:47 |
| mattoliver | And it's already merged thanks to acoles and timburke__ | 07:47 |
| cschwede | Yes, I was a bit surprised too. This was actually found when writing some new tempest tests by our new QE team member | 07:47 |
| mattoliver | Anything else to bring up? | 07:47 |
| mattoliver | lol | 07:47 |
| acoles | not from me | 07:48 |
| mattoliver | Cool, thank I'm going to go make dinner for the fam. | 07:50 |
| mattoliver | Thanks for coming and thanks for working on swift | 07:50 |
| mattoliver | #endmeeting | 07:50 |
| opendevmeet | Meeting ended Wed Jul 30 07:50:22 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 07:50 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/swift/2025/swift.2025-07-30-07.06.html | 07:50 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/swift/2025/swift.2025-07-30-07.06.txt | 07:50 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/swift/2025/swift.2025-07-30-07.06.log.html | 07:50 |
| cschwede | Thanks mattoliver for running the mtg! | 07:51 |
| acoles | so I changed this one to 'Won't Fix' https://bugs.launchpad.net/swift/+bug/1179009 . One small step forwards! | 07:52 |
| edausq | hello, following this change: https://review.opendev.org/c/openstack/swift/+/940601 , I beleive we should update the api-ref. What do you think? Should I open a bug or something? | 13:48 |
| zigo | timburke__: I'd like to thank you for the Sigv4-streaming patch ! It's just great to have it. Any chance to have it backported to at least Epoxy ? | 14:32 |
| zigo | (maybe Tim is in PTO ?) | 14:33 |
| *** timburke__ is now known as timburke | 17:11 | |
| timburke | i'm around -- sorry i forgot about the meeting last week | 17:12 |
| timburke | edausq, good call! i can look at getting a patch together for it (unless you'd like to try?) | 17:12 |
| timburke | zigo, normally i'd hesitate to backport what's solidly feature work -- but with the recent moves by aws's clients and SDKs, it does start to feel like fixing a bug of "s3api doesn't work with boto3 out of the box". i can take a look at how bad the merge conflicts get ;-) | 17:14 |
| opendevreview | ASHWIN A NAIR proposed openstack/swift master: add minimal trace to get_hashes https://review.opendev.org/c/openstack/swift/+/954379 | 18:31 |
| opendevreview | ASHWIN A NAIR proposed openstack/swift master: replicator: Add sync_batches_per_revert option https://review.opendev.org/c/openstack/swift/+/839649 | 18:44 |
| opendevreview | ASHWIN A NAIR proposed openstack/swift master: add minimal trace to get_hashes https://review.opendev.org/c/openstack/swift/+/954379 | 18:45 |
| opendevreview | Tim Burke proposed openstack/swift master: api-ref: Document storage_policy in account listings https://review.opendev.org/c/openstack/swift/+/956190 | 19:55 |
| timburke | edausq, ^^^ | 19:56 |
| opendevreview | Tim Burke proposed openstack/swift stable/2025.1: s3request: refactor to introduce SigChecker classes https://review.opendev.org/c/openstack/swift/+/956191 | 20:18 |
| opendevreview | Tim Burke proposed openstack/swift stable/2025.1: Add support of Sigv4-streaming https://review.opendev.org/c/openstack/swift/+/956192 | 20:18 |
| opendevreview | Tim Burke proposed openstack/swift stable/2025.1: utils: Add CRCHasher and crc32c implementation https://review.opendev.org/c/openstack/swift/+/956193 | 20:18 |
| opendevreview | Tim Burke proposed openstack/swift stable/2025.1: s3api: Validate additional checksums on upload https://review.opendev.org/c/openstack/swift/+/956194 | 20:18 |
| opendevreview | Tim Burke proposed openstack/swift stable/2025.1: s3api: Add support for crc64nvme checksum calculation https://review.opendev.org/c/openstack/swift/+/956195 | 20:18 |
| opendevreview | Tim Burke proposed openstack/swift stable/2025.1: Add support of Sigv4-streaming https://review.opendev.org/c/openstack/swift/+/956192 | 20:51 |
| opendevreview | Tim Burke proposed openstack/swift stable/2025.1: utils: Add CRCHasher and crc32c implementation https://review.opendev.org/c/openstack/swift/+/956193 | 20:51 |
| opendevreview | Tim Burke proposed openstack/swift stable/2025.1: s3api: Validate additional checksums on upload https://review.opendev.org/c/openstack/swift/+/956194 | 20:51 |
| opendevreview | Tim Burke proposed openstack/swift stable/2025.1: s3api: Add support for crc64nvme checksum calculation https://review.opendev.org/c/openstack/swift/+/956195 | 20:51 |
| opendevreview | Tim Burke proposed openstack/swift stable/2025.1: s3request: refactor error handling while reading input https://review.opendev.org/c/openstack/swift/+/956200 | 20:51 |
| opendevreview | Tim Burke proposed openstack/swift master: Forward-port stable-release CHANGELOG entries https://review.opendev.org/c/openstack/swift/+/956201 | 21:00 |
| timburke | zigo, that turned into more backports than i was expecting... and that's after dropping some of the follow-ons. (acoles, would we want to also backport, say, https://github.com/openstack/swift/commit/1a27d1b8 or https://github.com/openstack/swift/commit/351ee727 to feel like we had the test coverage we want to support a stable release?) | 21:06 |
| timburke | zigo, alternatively, is the ask specifically for a *stable* release that includes aws-chunked support, or *any* release? it's been *ages* since i actually did an intermediary release; i should really get back in that habit | 21:08 |
| timburke | hmm... we might also want to try to get https://review.opendev.org/c/openstack/swift/+/949671 across the line... otherwise keystone users might get some random 501s :-( | 21:29 |
| timburke | somewhat related to that -- i don't run with keystone for auth, but zigo, i'm assuming you do, yeah? would you agree with my premise in https://review.opendev.org/c/openstack/swift/+/951352 that trying to allow keystone users s3api access without enabling secret caching is basically setting yourself up for trouble? | 21:32 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!