21:00:04 <timburke> #startmeeting swift
21:00:04 <opendevmeet> Meeting started Wed Jan 24 21:00:04 2024 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:04 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:04 <opendevmeet> The meeting name has been set to 'swift'
21:00:10 <mattoliver> ok attempt 2 🤦
21:00:15 <timburke> who's here for the swift team meeting?
21:00:19 <mattoliver> o/
21:02:08 <timburke> as usual, the agenda's at
21:02:10 <timburke> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:02:17 <timburke> first up
21:02:20 <timburke> #topic eventlet
21:02:33 <timburke> good news! things seem to be pretty well fixed
21:02:42 <acoles> o/
21:03:00 <timburke> requirements rollback went through, unblocking our gate
21:03:15 <mattoliver> \o/
21:03:33 <timburke> new eventlet's been released, so the NameError won't be a problem the next time requirements bumps up eventlet
21:04:19 <zaitcev> Nice.
21:04:39 <timburke> and various patches surrounding the issue have landed, meaning (1) our tests currently pass with newest eventlet and (2) the cross-project job would now be capable of catching that eventlet bug
21:05:34 <timburke> i also put together a patch to indicate that we don't recommend using eventlet 0.34.3
21:05:37 <timburke> #link https://review.opendev.org/c/openstack/swift/+/906435
21:05:38 <patch-bot> patch 906435 - swift - Prevent installation of known-broken eventlet - 1 patch set
21:06:18 <timburke> but it looks like we'd need to also do a requirements change to add the known-bad version, and idk if it's worth the effort
21:06:29 <JayF> I'll note I would not expect that eventlet version bump to happen during C at this point. o/
21:08:09 <timburke> good to know, thanks JayF
21:08:58 <timburke> as part of all this, i did verify that our unit tests pass on all other versions of eventlet, for at least some version of python
21:09:15 <timburke> so that was reassuring :-)
21:09:38 <mattoliver> nice
21:09:40 <acoles> timburke: thanks for getting us back on track
21:10:20 <timburke> i think that's about it for this topic -- and it sounds like we shouldn't need to worry about it again for a bit :-)
21:10:32 <timburke> #topic part-number support
21:10:43 <timburke> #link https://review.opendev.org/c/openstack/swift/+/894570
21:10:43 <patch-bot> patch 894570 - swift - slo: part-number=N query parameter support - 86 patch sets
21:10:48 <timburke> #link https://review.opendev.org/c/openstack/swift/+/894580
21:10:49 <patch-bot> patch 894580 - swift - s3api: Support GET/HEAD request with ?partNumber - 94 patch sets
21:11:12 <timburke> i took a look at the slo patch, but still need to get to the s3api patch
21:11:14 <acoles> "94 patch sets" - can we make it to 3 digits???
21:11:35 <timburke> as part of that, i kicked up a follow-up
21:11:40 <timburke> #link https://review.opendev.org/c/openstack/swift/+/906391
21:11:41 <patch-bot> patch 906391 - swift - slo: Support range requests for part-number queries - 1 patch set
21:12:39 <acoles> I'm curious if that breaks the s3api patch - s3api definitely doesn't allow partNumber and Range, and I assume it may be relying on SLO to disallow it
21:13:56 <timburke> i'm still a little unsure about some of the boundaries/division of responsibilities in the first patch, but indianwhocodes is out for a bit, so it might be a bit before we can get it merged
21:15:39 <timburke> i think mattoliver was planning on taking a look, too, though; maybe he'll tell me to let it go and just merge it ;-)
21:16:51 <timburke> acoles, good thought -- should be easy enough for s3api to enforce that, yeah?
21:17:19 <acoles> what's the use case when a client knows the part number and a range within it, but not the part's range i.e. why can't the client figure out the absolute range
21:17:25 <mattoliver> yeah I do still plan too. Got distracted on Al's follow up container get auto refactor patch and downstream stuff again :( But it is on my list. And my summer holiday vacation kid parenting time off is now over to back full time
21:17:33 <acoles> yeah, s3api might just need to do its own policing
21:17:50 <timburke> oh, unless it's not an MPU, maybe? have we tested ?partNumber=1 w/ Range against a non-MPU on aws?
21:18:04 <timburke> (bleh, that's a lot of clauses)
21:20:31 <acoles> we should add that cross-compat test if we don't have it
21:21:50 <timburke> but acoles is right -- if a client wants to resume a part download, it should be doable to just adjust the range and go against the whole object -- though i think you'd have to sign a new request (since you'd be dropping the query param
21:22:27 <timburke> #topic py312 (and in general, future platforms work)
21:23:01 <timburke> i wanted both to remind people about the outstanding patches
21:23:03 <timburke> #link https://review.opendev.org/q/project:openstack/swift+topic:py312
21:23:31 <timburke> and alert y'all to a new bug found on debian-bookworm and ubuntu-noble
21:23:36 <timburke> #link https://bugs.launchpad.net/swift/+bug/2051067
21:23:37 <patch-bot> Bug #2051067 - Malformed database test won't raise DatabaseError on new sqlite (Confirmed)
21:24:28 <timburke> that affects more than just py312 (py311, at least) as it's at the sqlite layer, but seems somewhat related
21:25:43 <timburke> i'll probably spend some time building sqlite from source in the near future, trying to figure out why/how our test DB is malformed, and what changed that sqlite no longer thinks so
21:26:33 <timburke> if anybody has any clues/tips, i'd appreciate it, but it goes back a while and the git history isn't terribly informative
21:28:04 <zaitcev> My first instinct is to give up immediately, and load an auditor with a yet another trick to identify bad databases. By checksumming some kind of key digest or whatever.
21:29:10 <timburke> yeah; some kind of DB checksumming could be nice -- makes me think of https://bugs.launchpad.net/swift/+bug/1823785
21:29:11 <patch-bot> Bug #1823785 - Container replicator can propagate corrupt timestamps (New)
21:29:55 <mattoliver> yeah I've noticed this test failing lately.
21:30:23 <timburke> mattoliver, really! what platform/python version?
21:31:03 <mattoliver> I feel like I've been seeing it when I run tox -epy39
21:31:17 <mattoliver> So is it more systemic?
21:31:45 <mattoliver> but my fedora 39 environment runs much newer python.
21:31:49 <timburke> which os? do you know what sqlite version you're on?
21:32:01 <mattoliver> oh let me check
21:32:06 <timburke> ah, yeah, i could see fedora keeping on a pretty new sqlite...
21:32:34 <mattoliver> $ rpm -qa |grep sqlite
21:32:34 <mattoliver> sqlite-libs-3.42.0-7.fc39.x86_64
21:32:34 <mattoliver> sqlite-3.42.0-7.fc39.x86_64
21:33:30 <timburke> seems to make sense -- i don't see the failure on jammy (sqlite 3.37.2), but do on bookworm (sqlite 3.40.1)
21:33:54 <mattoliver> kk, so maybe its 3.40+
21:34:16 <mattoliver> I'll have a poke seeing as I have an env it's problematic on.
21:35:14 <timburke> my plan is to (1) assess why it was malformed before, and whether sqlite is trying to correct the error or somehow missed it, and (2) find a new way to mangle a DB that will trip the error on old & new sqlite
21:36:04 <mattoliver> yeah I can just open the malformed db in sqlite nowdays, I assume you can't in jammy
21:36:19 <mattoliver> I can test that, I have a vsaio here somewhere
21:36:40 <timburke> i'm willing to bet that sqlite found a way to not just detect but also correct the error, 'cause that seems to be the sort of thing they'd do, but i didn't see anything in their release notes that leapt out as explaining the change
21:37:06 <timburke> mattoliver, you should be able to get to a sqlite prompt, but querying the 'test' table fails
21:37:45 <timburke> anyway, that's all i've got
21:37:49 <timburke> #topic open discussion
21:38:01 <timburke> anything else we ought to bring up this week?
21:38:16 <mattoliver> $ sqlite3 swift/test/unit/common/malformed_example.db... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/DHPWlcErVQwtJZQDakvhySCD>)
21:39:17 <mattoliver> dang it, I've been nerd sniped :P
21:39:23 <timburke> :D
21:40:15 <mattoliver> Ahh, I have pushed up some tests for p 905064
21:40:16 <patch-bot> https://review.opendev.org/c/openstack/swift/+/905064 - swift - wip: shard replication sync points - 5 patch sets
21:40:38 <mattoliver> although it isn't an urgent patch, just scratching an itch
21:42:05 <mattoliver> new test doesn't work on py2 too well because row order seems to be non-deterministic. So just skipping testing on py2 for now (in hopes we remove py2 support soon) :P
21:44:26 <timburke> the recent discussion makes me wonder whether it's a py2/py3 issue, or sqlite 3.x/3.y issue...
21:45:59 <timburke> but yeah, i'm really hopeful about being able to (finally!) drop py2 -- the cluster-management tool we've got on py2 finally has tests passing under py3
21:46:06 <mattoliver> maybe, except this is all happening on my fedora 39 laptop, so I'd assume it's using the same sqlite3 binary. different python mods I guess though 🤷
21:46:16 <mattoliver> \o/
21:46:41 <timburke> so now we just need to try actually running under py3, and see where all our testing gaps were :P
21:47:11 <zaitcev> Nice, I was tapping my foot, waiting for the open discussion just in order to ask when we're going to drop py2.
21:47:55 <timburke> as soon as i can once i no longer need to import swift code under py2 :-)
21:47:59 <mattoliver> so hopefully matter of weeks then.. or do we bite the bullet and do it sooner rather then later, and we just deal downstream :)
21:50:27 <timburke> well, i can start by rebasing https://review.opendev.org/c/openstack/swift/+/853590
21:50:27 <patch-bot> patch 853590 - swift - Drop py2 support - 10 patch sets
21:51:24 <mattoliver> Cool, true great start, so we have something ready. Anyway, not something we'd decide in the last few minutes of a meeting. But exciting times coming :)
21:51:29 <timburke> looks like i maybe need to revisit the lower-constraints patch on that one...
21:51:42 <zaitcev> timburke: so what is your overrall sense about the eventlet: are we going to stay with it and just fix py12, py313, as they come, or should we (Swift) try and find a new WSGI server?
21:52:22 <timburke> i think we'll need to do something different in the not-too-distant future
21:52:51 <timburke> which surely means addressing https://bugs.launchpad.net/swift/+bug/1496636
21:52:51 <patch-bot> Bug #1496636 - EC: Chunked transfer/commit protocol is *not* HTTP (In Progress)
21:53:52 <zaitcev> They uploaded https://www.youtube.com/watch?v=lSUSZ8xGF9o
21:54:32 <zaitcev> Unfortunately, it wasn't particularly impactful. Also, I have the video meetings.
21:54:44 <zaitcev> s/ have / hate /
21:54:58 <timburke> asyncio seems like it might be a reasonable alternative, though iirc jianjian saw some performance downsides -- i need to refresh my memory as to the exact numbers, though
21:55:22 <timburke> we get enough of those these days as it is ;-)
21:55:43 <zaitcev> asyncio is not the webserver. you need to choose aiowsgi, aiohttp, or something else.
21:56:25 <timburke> true enough
21:56:46 <JayF> There is a governance change up for OpenStack trying to identify a route forward
21:56:54 <JayF> if you have strong opinions please participate there
21:57:11 <JayF> https://review.opendev.org/c/openstack/governance/+/902585
21:57:11 <patch-bot> patch 902585 - governance - Modernize Openstack Networking Programming Model - 14 patch sets
21:57:14 <zaitcev> Yeah, Harve's driving it
21:57:53 <JayF> I have mostly stayed out and let Itamar do the talking from my perspective :)
21:59:13 <timburke> all right, we're about at time
21:59:26 <timburke> thank you all for coming, and thank you for working on swift!
21:59:31 <timburke> JayF, and eventlet ;-)
21:59:35 <timburke> #endmeeting