21:05:31 <timburke> #startmeeting swift
21:05:31 <opendevmeet> Meeting started Wed Oct  9 21:05:31 2024 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:05:31 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:05:31 <opendevmeet> The meeting name has been set to 'swift'
21:05:41 <timburke> who's here for the swift meeting?
21:05:44 <mattoliver> o/
21:06:25 * zaitcev peeks in and out
21:06:30 <timburke> ok, like i was saying, not too much to bring up this week
21:06:34 <timburke> #topic PTG
21:06:49 <timburke> it's soon! please register if you haven't
21:07:02 <timburke> #link https://ptg2024.openinfra.dev/
21:07:20 <mattoliver> I have! looking forward to it.. even if I'm up late :)
21:07:38 <timburke> please let me know what times work well for you if you haven't (i still need to book some slots)
21:07:46 <timburke> #link https://framadate.org/LQOsGVVWXDhXqQUw
21:08:14 <timburke> and please add topics to the etherpad
21:08:16 <timburke> #link https://etherpad.opendev.org/p/swift-ptg-epoxy
21:09:42 <timburke> if you can add some descriptions, that'd be great -- i filled in one of mine that was missing but still need to do the other
21:09:58 <timburke> and i'm sure i've got another topic or two lurking in my head that i ought to add :-)
21:10:15 <mattoliver> kk, I still haven't adding things, I'm sure I can come up with some topics :)
21:11:55 <timburke> even if you don't intend to add anything, please take a look at what others have added and add your nick to what you're most interested in
21:12:47 <timburke> shortly before the PTG starts, i plan to re-order topics so the most-popular are at the top and we'll try to get to them first
21:13:15 <mattoliver> also allows us to know who needsto be present (because they were interested)
21:14:49 <timburke> #topic bug #2081103
21:14:50 <patch-bot> https://bugs.launchpad.net/swift/+bug/2081103 - s3api: Deleting the current version of an object can (sometimes?) 500 (In Progress)
21:15:08 <timburke> fulecorafa, good news! i think i've got a fix
21:15:20 <timburke> #link https://review.opendev.org/c/openstack/swift/+/931325
21:15:20 <patch-bot> patch 931325 - swift - versioning: 411 PUTs with neither content-length n... - 2 patch sets
21:16:09 <timburke> there's *also* a separate eventlet bug, but i think we can dodge it OK with the swift change
21:16:32 <timburke> if anyone has a moment to review, i'd appreciate it
21:16:34 <mattoliver> oh cool
21:17:01 <indianwhocodes> i added a topic too, yay the same one from the last one
21:18:10 <timburke> #topic pyeclib wheels
21:18:34 <timburke> mattoliver has been hard at work the last day or two reviewing things! thanks, mattoliver!
21:19:23 <timburke> it's kicked up a few questions in my mind:
21:19:43 <mattoliver> yeah, finally loaded it all up and got to diving in.
21:20:05 <timburke> 1. mattoliver has just +2'ed -- do we want more people on board before merging?
21:20:19 <mattoliver> alpine seems to be a different beast and wonder if vendoring actually works there.
21:20:44 <mattoliver> I tihnk I'm happy to merge the first few, they work great. And much better then what we already have (nothing)
21:22:01 <timburke> 2. the arm64 wheel builds tend to take a while, because there just aren't that many arm64 nodes available. should we continue to require them for every pyeclib change going forward?
21:23:08 <timburke> 3. being able to build wheels that hopefully work is great -- but should we get something in place to actually validate the wheels that are built? the musllinux wheels caught me by surprise -- thanks for actually testing them, mattoliver
21:23:55 <mattoliver> 2 - we could just trigger them on a release? Or on the otherhand there isn't too many pyeclib changes (at the moment) and it might be nice to test.
21:24:09 <timburke> (actually, i know the answer to that last one. yes, yes we should. i suppose the real question is, do we want to require CI-driven wheel validation before we start publishing these wheels?)
21:24:57 <timburke> another thought i had on 2 was to look into cross-compiling, so we could maybe build aarch64 wheels on x86_64
21:25:10 <mattoliver> The apline might be faily easy to test, its just a docker image. I do have that dodgy test script I was using which just creates a pyeclib driver, encodes and then decodes with a random subset of the peices.
21:26:00 <mattoliver> To test aarch I needed to build a vm on my x86_64 box via qemu. which was fine.
21:26:19 <mattoliver> but we do have arm ci nodes which should make testing easier :shrug:
21:26:31 <mattoliver> even if they are already overloaded
21:27:18 <timburke> yeah, and fortunately i already figured out how to (1) make one job wait on another completing and (2) have a dependent job grab an artifact that was built
21:27:42 <mattoliver> oh cool, well that's a bunch of the missing peices already!
21:27:43 <timburke> since i needed both of those for p 927654
21:27:43 <patch-bot> https://review.opendev.org/c/openstack/pyeclib/+/927654 - pyeclib - Publish manylinux wheels - 10 patch sets
21:30:07 <timburke> oh yeah, mattoliver -- i wanted to check in: does your dodgytest.py just test with liberasurecode_rs_vand, or does it do some isal, too?
21:30:59 <mattoliver> only liberasurecode_rs_vand. but yeah I should extend it to isa_l. I'll test with that today.
21:31:13 <timburke> 👍
21:31:26 <mattoliver> makes sense. it was just enough to force using the liberasurecode library to make sure the wheel was working
21:32:45 <timburke> speaking of ec backends, i wanted to mention that there's p 908533
21:32:46 <patch-bot> https://review.opendev.org/c/openstack/pyeclib/+/908533 - pyeclib - Include jerasure in manylinux wheels - 10 patch sets
21:33:23 <timburke> ...but idk that we actually *should* include it -- seems like there are probably some patent issues we wouldn't want to mess with
21:34:01 <mattoliver> yeah, maybe let people install that themselves to keep us out of the sticky web that is jerasure patents.
21:38:04 <timburke> and on the musl troubles, i think the most recent version of p 929700 is fixed for liberasurecode_rs_vand at least
21:38:04 <patch-bot> https://review.opendev.org/c/openstack/pyeclib/+/929700 - pyeclib - Build musllinux wheels - 10 patch sets
21:38:04 <mattoliver> ok, test script not supports isa_l_rs_vand so let's see how that goes :)
21:38:32 <mattoliver> oh cool. I'll give it a go
21:39:01 <timburke> there might need to be another round to get isal working right, though
21:39:09 <timburke> all right, that's all i've got
21:39:13 <timburke> #topic open discussion
21:39:21 <timburke> what else should we bring up this week?
21:39:29 <mattoliver> on a side note, I notices wget or curl from the zuul artifacts was giving me a short read of the file (giving me broken wheels). But downloading then via the browser was fine. weird stuff
21:39:58 <mattoliver> nah, I'm good. I was on vacation last week, so still ramping up
21:44:02 <timburke> mattoliver, i think it's due to how zuul uploads get compressed -- IME tacking on a `--compressed` helps
21:44:31 <mattoliver> oh ok, that's great to know!
21:45:13 <timburke> i think for wget you'd want `--compression=auto` or something
21:47:03 <timburke> fortunately ansible's get_url does it for us so i don't have to worry about it in https://review.opendev.org/c/openstack/pyeclib/+/927654/10/tools/playbooks/release-wheel/download-artifacts.yaml
21:47:03 <patch-bot> patch 927654 - pyeclib - Publish manylinux wheels - 10 patch sets
21:47:27 <timburke> all right, i think i'll wrap up a little early
21:47:38 <timburke> thank you for coming, and thank you for working on swift!
21:47:42 <timburke> #endmeeting