| opendevreview | Matthew Oliver proposed openstack/swift master: Ring: Add some initial v2 documentation https://review.opendev.org/c/openstack/swift/+/864494 | 00:00 |
|---|---|---|
| opendevreview | Jianjian Huo proposed openstack/swift master: sharding: avoid transient overlaps while auditing. https://review.opendev.org/c/openstack/swift/+/864088 | 00:07 |
| opendevreview | Jianjian Huo proposed openstack/swift master: sharding: avoid transient overlaps while auditing. https://review.opendev.org/c/openstack/swift/+/864088 | 00:29 |
| opendevreview | Matthew Oliver proposed openstack/swift master: Prepare tracing by adding a WSGI mixin for middlewares https://review.opendev.org/c/openstack/swift/+/797811 | 06:24 |
| opendevreview | Matthew Oliver proposed openstack/swift master: trace: Add RequestTraceMiddleware with OpTel https://review.opendev.org/c/openstack/swift/+/857559 | 06:24 |
| opendevreview | Matthew Oliver proposed openstack/swift master: trace: Add RequestTraceMiddleware with OpTel https://review.opendev.org/c/openstack/swift/+/857559 | 07:11 |
| opendevreview | Alistair Coles proposed openstack/swift master: sharding: avoid transient overlaps while auditing. https://review.opendev.org/c/openstack/swift/+/864088 | 14:31 |
| opendevreview | Alistair Coles proposed openstack/swift master: proxy-server: include suppression time in error limit log https://review.opendev.org/c/openstack/swift/+/864199 | 15:02 |
| opendevreview | Alistair Coles proposed openstack/swift master: sharder: merge shard shard_ranges from root while sharding https://review.opendev.org/c/openstack/swift/+/852905 | 16:12 |
| opendevreview | Alistair Coles proposed openstack/swift master: WIP: ShardRange: add is_grandchild_of method https://review.opendev.org/c/openstack/swift/+/863894 | 16:12 |
| opendevreview | Alistair Coles proposed openstack/swift master: sharding: avoid transient overlaps while auditing. https://review.opendev.org/c/openstack/swift/+/864088 | 16:18 |
| opendevreview | Alistair Coles proposed openstack/swift master: db_auditor: remove logging translation https://review.opendev.org/c/openstack/swift/+/864775 | 18:33 |
| opendevreview | Alistair Coles proposed openstack/swift master: account_auditor: fix warning string https://review.opendev.org/c/openstack/swift/+/864776 | 18:33 |
| opendevreview | ASHWIN A NAIR proposed openstack/swift master: proxy-server exception logging shows replication_ip/port https://review.opendev.org/c/openstack/swift/+/860866 | 19:33 |
| opendevreview | ASHWIN A NAIR proposed openstack/swift master: proxy-server exception logging shows replication_ip/port https://review.opendev.org/c/openstack/swift/+/860866 | 19:46 |
| opendevreview | ASHWIN A NAIR proposed openstack/swift master: s3api errors for unsupported headers x-delete-at, x-delete-after https://review.opendev.org/c/openstack/swift/+/864788 | 20:40 |
| timburke | #startmeeting swift | 21:01 |
| opendevmeet | Meeting started Wed Nov 16 21:01:33 2022 UTC and is due to finish in 60 minutes. The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot. | 21:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 21:01 |
| opendevmeet | The meeting name has been set to 'swift' | 21:01 |
| timburke | who's here for the swift meeting? | 21:01 |
| acoles | \o | 21:01 |
| seongsoocho | o/ | 21:01 |
| mattoliver | o/ | 21:01 |
| timburke | sorry, haven't updated the agenda, so i'll be kinda making this up as i go ;-) | 21:02 |
| mattoliver | lol | 21:02 |
| kota | o/ | 21:02 |
| timburke | #topic failing func tests | 21:02 |
| timburke | as i mentioned last week, a recent cpython change broke some of our func tests | 21:03 |
| timburke | (specifically, ones that wanted to include a leading '//' in request paths) | 21:03 |
| timburke | the rest of openstack is looking to move base CI images from focal to jammy -- as things stand, that will mean that at least our dsvm job will fail | 21:05 |
| timburke | i've got a fix, but it's a bit of an ugly hack | 21:05 |
| timburke | #link https://review.opendev.org/c/openstack/swift/+/863441 | 21:05 |
| timburke | other options include either marking the job non-voting | 21:06 |
| timburke | or pinning it specifically to continue using focal | 21:06 |
| timburke | from talking with gmann, sounds like the transition to jammy will be friday | 21:07 |
| mattoliver | oh that's interesting. but annoying that we may need to support that behaviour. And I assume it does it before it hits our domain_remap middleware (ie up in wsgi). | 21:08 |
| timburke | yes -- before anything's even started building a WSGI environ, in fact. it's pretty low level | 21:08 |
| timburke | #link https://github.com/python/cpython/issues/99220 | 21:09 |
| timburke | for a little more context | 21:09 |
| timburke | so, can anyone help review the fix, make sure i'm not doing anything too egregious? and if we can't get it merged by then, are there strong opinions about how to ensure we don't start next week with a broken gate? my gut says to pin to focal for now | 21:11 |
| mattoliver | yup, I'll have a play with it | 21:11 |
| timburke | thanks mattoliver | 21:12 |
| timburke | next up | 21:13 |
| timburke | #topic large objects and swiftclient | 21:13 |
| opendevreview | ASHWIN A NAIR proposed openstack/swift master: s3api errors for unsupported headers x-delete-at, x-delete-after https://review.opendev.org/c/openstack/swift/+/864788 | 21:14 |
| timburke | i recently encountered some users uploading dlos then getting bit by listings showing them as 0-byte objects. they didn't really care about the dlo/slo distinction, they just wanted some >5GB objects written | 21:15 |
| timburke | and it occurred to me: we've had SLO for nearly ten years now. and while it isn't strictly required when deploying a swift cluster, my understanding is that it's generally available | 21:16 |
| timburke | so, should swiftclient switch to writing SLOs by default? | 21:16 |
| timburke | #link https://review.opendev.org/c/openstack/python-swiftclient/+/864444 | 21:17 |
| mattoliver | +1, I think in pretty much every case an SLO is better then a DLO. | 21:17 |
| timburke | there's still an escape hatch -- it adds a new `--use-dlo` flag. and the existing `--use-slo` option is still parsed, so we won't break existing workflows | 21:18 |
| seongsoocho | +1 to that idea :) | 21:19 |
| acoles | remind me, does swift info advertise if slo is supported? | 21:19 |
| timburke | i considered doing a /info call if neither flag was specified, then using slo if was available -- but that seemed overly complicated and would require an extra network round-trip | 21:20 |
| acoles | just wondering if the client could check before defulting to dlo | 21:20 |
| timburke | it could, yes | 21:20 |
| acoles | timburke: yeah, that :) | 21:20 |
| timburke | if i was focused on nothing but the client, i'd really push for getting some persistent cache into the client -- specifically for /info responses and tokens/storage-urls | 21:21 |
| acoles | what happens if client tries slo with a cluster that does not support it? | 21:22 |
| timburke | excellent question -- haven't tried it. sounds like a bug i remember seeing, though... | 21:22 |
| timburke | related question: should we start making slo a required middleware server-side? | 21:23 |
| acoles | just wondering if there is a fallback route to retry with dlow | 21:23 |
| acoles | err, if client defaults to slo then it certainly seems reasonable that clusters would provide it by default | 21:24 |
| timburke | here's the bug i was thinking about! looks like clayg did some investigation, and putting an SLO to a cluster that doesn't have it enabled just writes the manifest as an object :-( | 21:26 |
| timburke | #link https://bugs.launchpad.net/swift/+bug/1680083 | 21:26 |
| timburke | so i suppose maybe i ought to go ahead and do that /info call... | 21:27 |
| timburke | good news is that modern swiftclients don't send a X-Static-Large-Object header anymore https://review.opendev.org/c/openstack/python-swiftclient/+/455470/ | 21:28 |
| timburke | also makes me think that gatekeeper should probably strip out the header... | 21:29 |
| timburke | ok, i think i got the feedback i needed -- seems like we're generally agreed that the default should change, but it's worth the /info call to ensure that slo is actually available. i'll try to respin soon | 21:30 |
| mattoliver | kk | 21:30 |
| timburke | #topic ring v2 | 21:30 |
| timburke | thanks for looking at the initial patch again, mattoliver! | 21:30 |
| mattoliver | nps | 21:31 |
| timburke | and clayg's been offering some feedback recently internally | 21:31 |
| seongsoocho | 👏 | 21:32 |
| mattoliver | if people haven't seen I've put together a doc patch for it | 21:32 |
| mattoliver | #link https://review.opendev.org/c/openstack/swift/+/864494 | 21:32 |
| acoles | timburke: one last thought - the pre-check info could be disabled by an option?? | 21:32 |
| mattoliver | would --use-slo or --use-dlo not use the pre-check option | 21:32 |
| mattoliver | ie, if you say so | 21:32 |
| timburke | acoles, yes, that was my thinking -- if you explicitly say --use-slo or --use-dlo, skip the /info and assume the user knows what they're doing | 21:33 |
| acoles | yup :thu | 21:33 |
| timburke | based clayg's feedback, i might try putting out yet another take on how to structure v2 rings -- this time based on zipfile | 21:33 |
| acoles | sorry I am struggling with an unfamilar keyboard ... 👍 | 21:34 |
| acoles | mattoliver: docs! super! | 21:34 |
| timburke | and making the "sections" in the current patch into separate files within the zip | 21:34 |
| mattoliver | I guess the question is, can we seek and pull out files nicely or would we have the load the whole thing up | 21:36 |
| mattoliver | thinking when a ring includes the builder data too. | 21:36 |
| timburke | i think my main concerns would be around on-disk file size and speed of deserialization, but they'll be hard to judge until there's an implementation | 21:37 |
| timburke | yeah, zip includes a "central directory" at the end, which has the whole file structure and pointers to offsets for each file | 21:38 |
| mattoliver | well that's the other thing. We've had a few PTGs getting the current design together and a patch that works. | 21:38 |
| mattoliver | oh cool | 21:38 |
| timburke | it'll involve some other changes to look for *either* a ring.gz or a ring.zip -- which probably *also* means more changes for our internal ring-management tooling... | 21:39 |
| mattoliver | yup, it would give zeitcev what we are asking | 21:40 |
| mattoliver | ie, different names to you can see at an lls level | 21:40 |
| mattoliver | *ls | 21:40 |
| timburke | idk -- i thought zaitcev wanted a separate name specifically when it's also got builder info in it | 21:41 |
| zaitcev | (hold on, I wasn't looking for a moment, sorry) | 21:41 |
| timburke | no worries :-) | 21:41 |
| zaitcev | Okay, yes. I did want a separate name for the unified builder-ring thing. | 21:42 |
| zaitcev | I'm looking at the double-slash thing... | 21:43 |
| zaitcev | meanwhile, I mean | 21:43 |
| timburke | thanks! | 21:43 |
| timburke | i think this would also be fairly amenable to that -- having something like object.builder.zip | 21:43 |
| timburke | could maybe even have the search order for services be something like object.ring.zip else object.ring.gz else object.builder.zip | 21:45 |
| timburke | then write_ring could still be useful to have a snapshot while you're manipulating the builder | 21:46 |
| timburke | /shrug | 21:46 |
| timburke | anyway, i think that's all i've got | 21:47 |
| timburke | #topic open discussion | 21:47 |
| timburke | anything else we should bring up this week? | 21:48 |
| mattoliver | I've managed to get an in memory tracer working for unit tests. | 21:48 |
| timburke | \o/ | 21:48 |
| mattoliver | So started some basic tracing unit tests | 21:48 |
| mattoliver | not sure about cross service (ie in probe tests) but that's the next bit of testing | 21:49 |
| mattoliver | thats all I had for now | 21:53 |
| timburke | all right | 21:53 |
| timburke | thank you all for coming, and thank you for working on swift! | 21:53 |
| timburke | #endmeeting | 21:54 |
| opendevmeet | Meeting ended Wed Nov 16 21:54:00 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:54 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/swift/2022/swift.2022-11-16-21.01.html | 21:54 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/swift/2022/swift.2022-11-16-21.01.txt | 21:54 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/swift/2022/swift.2022-11-16-21.01.log.html | 21:54 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!