21:00:01 <timburke> #startmeeting swift
21:00:02 <openstack> Meeting started Wed Apr 15 21:00:01 2020 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:05 <openstack> The meeting name has been set to 'swift'
21:00:09 <timburke> who's here for the swift meeting?
21:00:13 <seongsoocho> o/
21:00:14 <kota_> o/
21:00:18 <mattoliverau> o/
21:00:19 <alecuyer> hello o/
21:00:35 <rledisez> o/
21:01:18 <timburke> i think tdasilva and clayg may be busy with another meeting...
21:01:32 <timburke> as usual, agenda's at
21:01:35 <timburke> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:01:51 <clayg> so oh i was planning on skipping that other meeting too 🤔
21:02:00 <timburke> haha
21:02:02 <timburke> #topic virtual PTG
21:02:16 <timburke> quick reminder to start gathering topics
21:02:25 <timburke> #link https://etherpad.opendev.org/p/swift-ptg-victoria
21:02:35 <timburke> i see clayg has already started :D
21:03:11 <timburke> i still need to catch up on the mailing list a bit to see what kind of logistical issues i need to pay attention to
21:03:52 <timburke> #topic tc election
21:04:05 <timburke> just highlighting that the election results are in
21:04:12 <timburke> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014135.html
21:04:46 <timburke> congrats to the new (and returning) tc members!
21:05:04 <timburke> #topic swiftclient
21:05:12 <timburke> the gate's fixed!
21:05:24 <seongsoocho> 🎉
21:06:12 <timburke> also, i threw up a bunch of patches -- https://review.opendev.org/#/c/719686/ seems like it'd probably warrant further discussion
21:06:12 <patchbot> patch 719686 - python-swiftclient - Rip out SERVICENET support - 2 patch sets
21:06:49 <clayg> I want to know how you came up with the idea for that patch?
21:07:01 <clayg> servicenet was a dumb idea for AGES - why rip it out now 😆
21:07:54 <timburke> (for context, i was looking at trying to replace all of our auth stuff in client.py with some plumbing into keystoneauth1, and the crap at https://review.opendev.org/#/c/719686/2/swiftclient/client.py@a557 seemed to present a problem)
21:07:55 <patchbot> patch 719686 - python-swiftclient - Rip out SERVICENET support - 2 patch sets
21:08:48 <timburke> maybe i could work around it with an authv1 plugin variant... but OTOH... less code is good
21:09:09 <clayg> less code IS good - i'm on board with ripping it out 👍
21:09:39 <clayg> it was super auth v1 specific - and I think getting onto the keystone plumbing would help make some other things simpler so I encourage this effrot now that I understand the context
21:10:02 <timburke> clayg, i think you were the one i was most worried about objecting, so... \o/
21:11:36 <timburke> and finally, on the release front... i'd meant to get a 3.10.0 client out ahead of the ussuri cutoff, but didn't quite make it
21:11:49 <timburke> but versionign support will be that much better when it comes in victoria ;-)
21:12:28 <timburke> that's about all i had by way of announcements -- any questions or comments before moving on to updates?
21:13:39 <timburke> #topic waterfall-ec
21:13:45 <timburke> clayg, how's it going?
21:15:48 <timburke> we'll check in on him again later ;-)
21:15:53 <clayg> not working on it right now
21:16:10 <clayg> still thinking about it tho!  I might have to put "fixing swift_zipkin" in front of going back to it
21:16:16 <timburke> 👍
21:16:19 <clayg> I feel like the visualizations will be useful
21:16:26 <timburke> #topic lots of small files
21:16:41 <timburke> alecuyer, rledisez: how's it going?
21:17:08 <alecuyer> I made good progress with the first "non cleanup" patch I'd like to send, but I have been pulled to something else. I hope to return to it soon
21:17:14 <alecuyer> So I'm afraid no further news
21:17:49 <rledisez> I saw you send some patches to feature/losf timburke, thx for that, i'll have a look into them
21:18:40 <timburke> yeah, they're not ready yet -- i was trying to fix up the losf func test job
21:19:32 <timburke> i'm guessing there was a change in the default python interpreter for the unittest job that it's inheriting from, but i'm not sure how to switch it back yet
21:20:13 <timburke> of course, eventually we'll need a py3 version of it anyway...
21:20:24 <timburke> idk. still thinking about how to proceed there
21:20:42 <timburke> #topic cors
21:21:01 <timburke> so i reworked the test harness a bunch
21:21:36 <timburke> unfortunately, i seem to have broken my once-working gate job in the process, so i still need to sort that out
21:22:50 <timburke> you can see some of the new style in https://review.opendev.org/#/c/533028/13/test/cors/test-object.js
21:22:50 <patchbot> patch 533028 - swift - Add some functional CORS tests - 13 patch sets
21:23:46 <timburke> the big benefit was that it let me do request chaining, like in https://review.opendev.org/#/c/710355/12/test/cors/test-s3-obj.js@160
21:23:47 <patchbot> patch 710355 - swift - s3api: Allow CORS preflight requests - 12 patch sets
21:24:18 <timburke> (in the previous patchsets, that test would just do the write and not clean up after itself)
21:25:19 <timburke> this *also* let me do test the workflow my users are actually interested in, which was initiating, uploading, and completing S3 MPUs
21:25:58 <mattoliverau> Nice
21:26:39 <timburke> that needed a bunch more work than i was originally expecting to get it to work; p 720098 had to touch most of the functions in s3api's multipart upload controller, plus slo
21:26:40 <patchbot> https://review.opendev.org/#/c/720098/ - swift - WIP: s3api: Allow MPUs via CORS requests - 2 patch sets
21:27:24 <timburke> makes me wonder if p 528106 might be ther better way to go
21:27:25 <patchbot> https://review.opendev.org/#/c/528106/ - swift - Move CORS to middleware. - 5 patch sets
21:29:31 <timburke> anyway, long story short: there's going to be some more work needed on it, though i still think those preliminary patches will be useful even before we get to the point that my users are happy ;-)
21:29:59 <timburke> #topic open discussion
21:30:08 <timburke> anything else we should bring up today?
21:30:39 <kota_> ah, can i ask quick question on py3 work?
21:30:46 <timburke> yeah!
21:31:32 <kota_> so I think Swift still wants to keep py2 on Ussuri (ref: https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html#projects-keeping-py2-7-support) but I'm not sure if there are known issues yet.
21:32:01 <timburke> known issues with py2 or py3?
21:32:07 <kota_> so if some links (e.g. etherpad) to know issues let me know.
21:32:09 <kota_> ah, py3
21:32:21 <kota_> the context is from dropping py2 support for storlets
21:32:25 <timburke> osa brought https://bugs.launchpad.net/swift/+bug/1872553 to my attention just the other day
21:32:25 <openstack> Launchpad bug 1872553 in OpenStack Object Storage (swift) "fallocate_reserve is still broken on py3" [Undecided,New]
21:32:57 <kota_> openstack infra team actively pushed some patches to drop py2-compatible code and I'd like to check the status of Swift itself.
21:33:19 <kota_> drop py2-compatible code for Storlets
21:33:19 <timburke> yeah, makes sense. fwiw, i still don't have any clusters on py3 yet beyond my dev saio
21:34:03 <kota_> oic https://bugs.launchpad.net/swift/+bug/1872553 is absolutely one of big problems.
21:34:03 <openstack> Launchpad bug 1872553 in OpenStack Object Storage (swift) "fallocate_reserve is still broken on py3" [Undecided,New]
21:34:04 <timburke> i really want to change that, but... it's hard to squeeze in
21:35:23 <timburke> https://bugs.launchpad.net/swift/+bug/1863053 was another fairly recent one that caught me by surprise, but it has a fix on master and backported to train
21:35:23 <openstack> Launchpad bug 1863053 in OpenStack Object Storage (swift) "Swift on py3 doesn't like message/rfc822 data" [High,Fix released] - Assigned to Tim Burke (1-tim-z)
21:35:40 <kota_> good
21:37:13 <timburke> there was also a formpost issue, and s3api header casing -- i should probably do a 2.23.2 with more py3 fixes as i get 2.25.0 together...
21:37:29 <kota_> was sort of the communication between proxy and object fixed? I think some issues exist on MIME protocol on eventlet...
21:39:06 <timburke> yeah, https://bugs.launchpad.net/swift/+bug/1840507 was fixed ahead of the initial train release
21:39:06 <openstack> Launchpad bug 1840507 in OpenStack Object Storage (swift) "Mixed py2/py3 environment allows authed users to write arbitrary data to the cluster" [Undecided,Fix released]
21:39:53 <kota_> nice
21:39:53 <timburke> (unless there's some other issue i wasn't aware of)
21:40:57 <kota_> ok. thx. anything else you remember later, please let me know.
21:41:16 <kota_> and the situation on Swift upstream fits my idea.
21:41:40 <kota_> we still needs more production clusters on py3 and make them stable.
21:41:58 <kota_> before dropping py2.
21:42:25 <timburke> kota_, do you have a feeling for how storlets users usually deploy their swift these days? i'd say that should be your main input in deciding whether to continue supporting py2
21:43:56 <kota_> i don't have enough input from users but some users like hosanai was not actively upgrade the swift IIRC
21:44:06 <timburke> arguably, even if rledisez and clayg were running all py3-only, if there were significant numbers of storlets users still running py2, that should be enough reason for swift to continue supporting it
21:44:41 <kota_> I'm not sure he (they) wants to upgrade storlets independently but keep py2-code would be ok but the new code should be developed as py3
21:44:42 <timburke> mm. fair enough -- if they don't upgrade swift, do they still upgrade storlets?
21:46:40 <kota_> fortunately (or unfortunately) Storlets is now not having drastic change on codebase so we might accept to drop testing step by step.
21:47:20 <kota_> I don't think they upgrade storlets yet.
21:48:47 <kota_> IMHO, storlets can follow the Swift way so you don't have to think of "keeping py2 for storlets"
21:50:08 <timburke> and otoh, storlets should absolutely feel free to say they don't want to keep trying to support py2 -- i think you guys can do that any time between now and when swift finally does drop py2
21:51:12 <kota_> i see thanks
21:51:58 <kota_> that is the reason why I ask the status. before dropping py2 completely, I'd like to check py3 works on Swift :P
21:52:28 <timburke> all right, i'm gonna call it
21:52:37 <timburke> thank you all for coming, and thank you for working on swift!
21:52:41 <timburke> #endmeeting