21:00:43 <timburke> #startmeeting swift
21:00:43 <opendevmeet> Meeting started Wed Feb 26 21:00:43 2025 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:43 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:43 <opendevmeet> The meeting name has been set to 'swift'
21:00:51 <timburke> who's here for the swift meeting?
21:00:56 <mattoliver> o/
21:01:07 <boosungkim[m]> hello
21:01:47 <timburke> as usual, the agenda's at
21:01:49 <timburke> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:02:00 <timburke> first up
21:02:06 <timburke> #topic failing DSVM jobs
21:02:54 <timburke> so a recent python-openstackclient release broke keystone credential creation, which our DSVM jobs use so we can test keystone+s3api
21:03:34 <timburke> the good news is there's a fix which has merged
21:03:40 <timburke> #link https://review.opendev.org/c/openstack/python-openstackclient/+/942721
21:03:52 <mattoliver> oh nice
21:03:55 <timburke> and there's even been a release to include the fix
21:04:08 <timburke> #link https://review.opendev.org/c/openstack/releases/+/942834
21:04:41 <timburke> the bad news is that the update to global requirements is going to fail
21:04:43 <timburke> #link https://review.opendev.org/c/openstack/requirements/+/942845
21:05:21 <timburke> ...because all the recent jobs have been failing: https://zuul.opendev.org/t/openstack/builds?job_name=requirements-tox-py312-check-uc&project=openstack/requirements
21:06:12 <timburke> that leaves us with a few options:
21:06:48 <timburke> 1. just wait until this all gets resolved
21:07:06 <timburke> 2. mark our dsvm jobs non-voting until it gets resolved
21:07:34 <timburke> 3. stop testing keystone+s3api until it gets resolved
21:08:30 <timburke> i'm kind of inclined toward 1 (or at least give things another day or two before doing anything else)
21:10:01 <mattoliver> how long do we think the wait is?
21:10:44 <timburke> dunno -- but https://review.opendev.org/c/openstack/swift/+/940059 has been trying to merge for a couple days now
21:11:12 <timburke> eh, i'll at least give it till the end of the week, re-evaluate monday
21:12:07 <timburke> speaking of requirements, i should go poke someone about https://review.opendev.org/c/openstack/requirements/+/941708 ... it'd be nice to be able to use subtests
21:12:32 <mattoliver> kk, sounds like a plan then
21:12:32 <jianjian> btw, what's DSVM?
21:13:53 <timburke> good question! "devstack vm" -- it's a job that builds on https://github.com/openstack/devstack/ which is kind of like a SAIO but for all of openstack
21:14:29 <mattoliver> its some intergrated rest of openstack tests via openstack devstacks (the main openstack dev env tool).
21:14:53 <jianjian> oh, I see. that's why you also suggested second option "mark our dsvm jobs non-voting until it gets resolved"
21:16:57 <timburke> between 2 and 3, i'm kinda torn: on the one hand, ignoring the whole test suite isn't great, but on the other, at least there'll be a constant reminder that the temporary fix is in place since those job results will have a (non-voting) flag
21:17:21 <timburke> we'll cross that bridge when we get there
21:17:33 <timburke> #topic PTG
21:17:59 <jianjian> okay, thanks for trying to fix it
21:18:18 <timburke> i almost forgot, but i set up a time slot poll and put up a skeleton etherpad for topics
21:18:37 <timburke> #link https://framadate.org/LBfzMX2I4C1JL9cZ
21:19:08 <timburke> #link https://etherpad.opendev.org/p/swift-ptg-flamingo
21:19:39 <timburke> and again, that'll be Apr 7-11
21:19:53 <jianjian> \o/
21:20:10 <mattoliver> cool, nice one timburke I'll fill out what I can of both :)
21:21:22 <timburke> i should double check whether they've mentioned official time slots yet or not -- i made the poll with the assumption that they'd have the same slots as the last several vPTGs
21:22:49 <timburke> though as mattoliver mentioned last week, it might not matter too much given that we could just all join a meetpad at some time regardless
21:23:31 <timburke> all right, next up
21:23:36 <timburke> #topic aws-chunked
21:24:05 <timburke> i think acoles and i are coming around to feeling like the new protocol's mostly ready
21:24:12 <timburke> #link https://review.opendev.org/c/openstack/swift/+/836755
21:24:30 <timburke> there are some rough edges, but we can always refine it on master
21:25:51 <timburke> i think the biggest hesitation to merging it right now is that we don't respect any additional checksums that might be sent -- so clients may not have the data-integrity guarantees they were expecting
21:27:19 <timburke> those patches still seem a little ways out -- there are some complications involving getting extra data into container listings and sending some metadata in footers
21:27:27 <mattoliver> yeah. If we land the first patch, do you think we can get the algorithm follow ups in before the next swift release?
21:27:45 <mattoliver> if so, I'd worry less because they're coming.
21:28:18 <timburke> i'd be nervous about that -- we need to get a swift release out in the pretty near term since we're getting to the end of the cycle
21:29:39 <timburke> one thought we had though was to get *partial* support -- just enough that we can reject uploads if checksums don't match, but don't bother writing anything down
21:30:24 <mattoliver> what would be the minimal we'd need to support initially? crc64?
21:30:49 <timburke> but i need to see how much of it we need to implement to make sure MPU uploads both work and protect against bit-flips
21:31:01 <mattoliver> I wouldn't mind getting some crc support in swift, even if it just starts in s3api, then we can use it more internally later.
21:31:07 <mattoliver> yeah kk
21:31:45 <timburke> iirc boto3 defaults to crc32, but some other clients are known to use crc32c. from docs, it seems like AWS is pushing for crc64-nvme
21:32:50 <mattoliver> see I'm on the fence. I want the chunked stuff in so people can use the most recent boto and it works.
21:33:19 <timburke> fortunately the actual algos aren't terribly difficult to implement -- the tricky parts are storing the results, and combining partial crcs to give a full-object crc for MPUs
21:33:52 <timburke> same. it sucks that what was previously a pretty well-supported client is now broken by default
21:34:39 <mattoliver> Does the patch need to have a doc warning that aws-chunked is partially supported with the extra argoritim caveats?
21:35:07 <mattoliver> Then we can land it, but make it known the rest is still in development.
21:35:27 <mattoliver> I mean we'd still md5 behind the scenes, we just don't check their given crcs
21:36:38 <timburke> i think for the most part *users* don't really know or care -- the *client* is just making decisions and the user is trusting it. so idk that a doc fix is really the right way to look at it -- the user probably neither knows nor cares about that level of implementation detail
21:37:05 <mattoliver> yeah, but it covers our butt :P
21:38:43 <timburke> i think as much as anything i just wanted to give some context -- there might be some new patches to split it like "respect additional checksums on upload" / "store additional checksums"
21:38:53 <timburke> we'll see how my investigation goes
21:39:08 <timburke> last topic from me
21:39:13 <timburke> #topic swift release
21:39:25 <timburke> it's that time in the cycle again!
21:39:36 <mattoliver> \o/
21:39:53 <timburke> we already have a new swiftclient release out (not that it has any material changes from the last release)
21:40:07 <mattoliver> shall we update swift priority reviews with patches we might want to try and include (those that are close) in the next release?
21:40:22 <mattoliver> And we might need to swift-bench release :P
21:40:28 <timburke> so i'm going start getting release notes together for a swift release
21:40:46 <timburke> yeah, priority reviews page is probably a good idea
21:40:46 <mattoliver> maybe just replace it with ssbench, swift-bench ng :P
21:41:22 <timburke> we've got a few patches that already have +2s
21:41:24 <timburke> #link https://review.opendev.org/q/p:openstack/swift+label:Code-Review%252B2+is:open+-age:26w
21:41:43 <timburke> #undo
21:41:43 <opendevmeet> Removing item from minutes: #link https://review.opendev.org/q/p:openstack/swift+label:Code-Review%252B2+is:open+-age:26w
21:41:57 <timburke> #link https://review.opendev.org/q/p:openstack/swift+label:Code-Review%2B2+is:open+-age:26w
21:42:31 <timburke> ...but again, we need a working gate before we can land anything anyway ;-)
21:42:44 <timburke> *including* release notes :P
21:43:07 <mattoliver> lol
21:43:34 <jianjian> haha
21:43:38 <timburke> so that's a decent part of why i'm thinking about contingencies in case the requirements stuff takes a bit to resolve
21:44:13 <jianjian> I remember Tim said he would like this patch to land into this release: https://review.opendev.org/c/openstack/swift/+/938631
21:44:42 <mattoliver> yeah, well I lean towards 1 then 3 then 1. So we still get intergration testing and just loose keystone + s3api for a bit.
21:44:54 <mattoliver> s/1/2/
21:45:07 <jianjian> I had +1, Clay had +2, Tim, are you still planning to do anything, or we should just merge it?
21:45:08 <timburke> jianjian, yeah, i still think that's a good idea
21:45:30 <mattoliver> yup, add it to prioirty reviews
21:45:56 <timburke> i've not given the patch much though in weeks. let's merge it if y'all think it's ready
21:46:13 <timburke> much thought*
21:46:39 <jianjian> okay, I will look at it again later this week
21:47:03 <timburke> thansk
21:47:12 <timburke> man, i can't type today
21:47:20 <jianjian> 😉
21:47:47 <timburke> all right, that's all i've got
21:47:51 <timburke> #topic open discussion
21:48:03 <timburke> anything else we should bring up this week?
21:49:39 <timburke> oh! a couple weeks ago, i saw someone wanting to clean up some of the pyeclib test matrix: https://review.opendev.org/c/openstack/pyeclib/+/941122
21:49:56 <timburke> which refreshed my memory about my own plan to do that: https://review.opendev.org/c/openstack/pyeclib/+/938098
21:50:50 <timburke> we should decide what versions of python we actually want to be supporting -- currently pyeclib is testing against 10 different minor versions!
21:51:16 <timburke> i want to cut that in half
21:51:46 <mattoliver> oh cool. pyeclib, I'll take a look
21:52:43 <timburke> thanks mattoliver -- if you like that one, there's a whole chain of stuff we could look at cleaning up since we don't have to worry about old python
21:54:00 <timburke> all right, i think i'll call it
21:54:11 <timburke> thank you all for coming, and thank you for working on swift!
21:54:14 <timburke> #endmeeting