21:00:03 <timburke> #startmeeting swift
21:00:04 <openstack> Meeting started Wed Apr  8 21:00:03 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:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:07 <openstack> The meeting name has been set to 'swift'
21:00:10 <timburke> who's here for the swift meeting?
21:00:17 <seongsoocho> o/
21:00:26 <kota_> hi
21:00:27 <rledisez> o/
21:01:04 <tdasilva> o/
21:01:29 <clayg> ohai
21:01:37 <clayg> i may have to duck out early
21:01:40 <timburke> as usual, the agenda's at https://wiki.openstack.org/wiki/Meetings/Swift
21:01:44 <clayg> lucky I'm only here for the lawlz
21:01:44 <timburke> no worries
21:02:00 <timburke> yeah, "updates" may be short ;-)
21:02:15 <timburke> i know *i'm* having a hard time getting much accomplished
21:02:25 <timburke> so, some announcements!
21:02:30 <timburke> #topic virtual PTG
21:02:40 <timburke> #link https://etherpad.openstack.org/p/swift-ptg-victoria
21:02:49 <timburke> i set up an etherpad to collect topics
21:03:19 <timburke> that's the extent of what planning i've done, though -- i'm having a hard enough time thinking two days into the future, much less two months
21:04:15 <timburke> i know there are mailing list threads and etherpads going around trying to aggregate openstack's collective wisdom around doing virtual hackathons, though
21:04:37 <timburke> #topic TC election
21:04:59 <timburke> there's more candidates than open seats this time!
21:05:16 <timburke> so please go read people's stances and vote
21:05:41 <mattoliverau> Oh sorry I'm late, daylight savings changed in Oz which threw me, things are now an hour earlier. o/
21:06:00 <timburke> not to worry!
21:06:13 <mattoliverau> I voted yesterday. Get in early so I don't forget :)
21:06:27 <clayg> timburke: I'm scared and confused by the TC vote - I have enough hard time just figuring out my texas rail road commissioner - can you just tell us who to vote for?
21:06:33 <clayg> mattoliverau: scratch that - can YOU tell me who to vote for?
21:06:39 <mattoliverau> Lol
21:06:51 <timburke> mattoliverau, smart -- i still need to get step one done (read candidacy emails)
21:07:04 <timburke> i'll keep you posted clayg ;-)
21:07:23 <mattoliverau> Yeah, there is a link to those. IE in hit which made it easier
21:07:44 <mattoliverau> If I was fully awake and near a computer I'd find the links
21:08:07 <timburke> #link https://governance.openstack.org/election/
21:08:36 <mattoliverau> *in git
21:08:58 <timburke> the top section after timetables has links to candidates' announcements
21:09:45 <timburke> (speaking of elections, there was a snafu so my candidacy isn't acutally listed there, but i will be continuing as ptl)
21:10:28 <timburke> thanks for the reminders kota_ and notmyname, but i didn't quite get everything sorted in time ;-)
21:10:46 <timburke> #topic ironic as a top-level opendev project
21:10:48 <kota_> :)
21:11:00 <timburke> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-April/013757.html
21:11:28 <mattoliverau> Oh I was going to mention this
21:11:29 <timburke> there's an interesting thread about ironic considering moving toward being more independent from openstack
21:11:53 <timburke> soemthing worth following, for sure
21:12:12 <mattoliverau> +1
21:12:16 <clayg> timburke: thanks!
21:12:25 <kota_> interesting
21:13:22 <timburke> ok, on to a couple more swift-specific things
21:13:28 <timburke> #topic python-swiftclient gate
21:13:33 <timburke> it's broken!
21:13:49 <kota_> :/
21:13:50 <timburke> we haven't noticed, because we so rarely propose changes there ;-)
21:14:05 <timburke> i *think* https://review.opendev.org/#/c/718309/ should fix it, though
21:14:06 <patchbot> patch 718309 - python-swiftclient - Blacklist stestr 3.0.0 - 2 patch sets
21:14:59 <timburke> in general, the further along the py3-only path everything else goes, the more breakage we'll likely see
21:15:32 <timburke> though afaict, *swift's* current gate woes aren't actually related to that
21:15:47 <timburke> i feel like i've been typing "recheck" a lot lately, though :-(
21:16:01 <rledisez> timburke: how long do you think it's gonna be sustainable to maintain a py2 code? is there any risk we have to drop py2 before the date we decided?
21:17:23 <timburke> biggest risk is in py3-only bugs
21:17:53 <timburke> things like https://review.opendev.org/#/c/707312/ kinda scare the bejesus out of me
21:17:54 <patchbot> patch 707312 - swift - py3: stop barfing on message/rfc822 Content-Types (MERGED) - 2 patch sets
21:19:00 <clayg> rledisez: getting rid of py2 support is the only interesting thing about supporting py3 - I only want to support both while we're working on switching our prod over to py3
21:19:03 <timburke> well, no -- *really*, https://review.opendev.org/#/c/682173/ scares me. the stupid rfc822 thing was mostly annoying
21:19:03 <patchbot> patch 682173 - swift - proxy: Don't trust Content-Length for chunked tran... (MERGED) - 4 patch sets
21:19:17 <clayg> the DAY after we finally get py3 working I want to remove py2 🤣
21:19:48 <clayg> maybe we *should* draw a line in the sand and say "swift can't support py2 anymore because py2 is dead; support will be removed soon"
21:19:58 <clayg> even if we know we can't remove it until at least WE manage to get off it
21:20:07 <clayg> it's not optional anymore - we waited as long as we could
21:20:23 <timburke> i should make sure we have a question related to py2 vs py3 in the user survey...
21:20:25 <clayg> but py3 is going to be amazing - we'll always have bugs to fix - the sooner we're running in prod the sooner we find them 💪
21:20:28 <rledisez> clayg: totally agree. i'm planning on deplying some py3 on prod in the next few months. but it's gonna be a very slow process…
21:20:46 <timburke> i look forward to the bug reports ;-)
21:20:51 <clayg> rledisez: same, very slow - it's not the upgrade - it's the eco-system of code that goes along with it 😢
21:21:44 <timburke> unwinding the stack a little, speaking of how difficult it's been lately to get patches through...
21:21:58 <timburke> #topic ussuri releases (both client and server)
21:22:39 <timburke> i should start getting releases together *now*, so there's some hope of having them actually happen by their deadlines :P
21:23:19 <clayg> 😬
21:23:20 <timburke> if there's anything you feel should be included, let me know! or just review and merge it ;-)
21:24:01 <timburke> i'm going to try to get the versioning support at least into swiftclient, then probably cut its release not long after that
21:24:22 <kota_> sounds good
21:24:34 <timburke> i think that about does it for announcements... any other comments or questions?
21:25:25 <timburke> all right, on to updates!
21:25:30 <timburke> #topic waterfall EC
21:25:52 <timburke> clayg, any chance to make progress on this, or are you still busy with other stuff for the most part?
21:28:31 <timburke> i'll take that as a no, too busy ;-) thanks for doing some reviews lately!
21:28:56 <timburke> maybe i should drop the topic for now, and clayg can add it back when he's ready...
21:29:03 <timburke> #topic lots of small files
21:29:04 <clayg> no problem - i'd be happy to squeeze in some reviews
21:29:14 <clayg> I did add waterfall to the list of topics
21:29:34 <rledisez> so alecuyer is not here, but he gave me some informations
21:29:58 <timburke> rledisez, yeah, you guys have been busy lately :D
21:30:06 <rledisez> he posted today a patch that is meant to cleanup some things in LOSF and get back to normal (hashes.pkl)
21:30:15 <rledisez> #link https://review.opendev.org/#/c/718445/
21:30:15 <patchbot> patch 718445 - swift (feature/losf) - Use hashes.pkl files for LOSF and remove list_part... - 1 patch set
21:30:30 <rledisez> he should post tomorrow an other cleanup patch about protobuf arguments
21:31:09 <rledisez> after that, he will start to send the new features (new key format, new volume selection algorithm and metadata stored in the KV)
21:31:37 <rledisez> that's it for losf
21:31:47 <timburke> 👍
21:31:50 <timburke> thanks!
21:31:56 <timburke> #topic cors
21:32:46 <timburke> so i've got a dirty tree locally that's partway through re-writing the js tests... i should finish that rewrite, but haven't found time
21:33:06 <timburke> i suppose i should mark it WIP for now
21:33:24 <timburke> that's about it, though
21:33:29 <timburke> #topic open discussion
21:33:40 <timburke> anything else we ought to talk about?
21:34:10 <rledisez> just a note about that random failure I've been hitting on https://review.opendev.org/#/c/704892/
21:34:11 <patchbot> patch 704892 - swift - proxy: stop sending frags to PyECLib with a Queue - 2 patch sets
21:34:27 <rledisez> i found the bad test. I don't understand why, but if I disable it, no more random failure
21:34:52 <rledisez> if anybody have a clue, i'm taking it :)
21:34:52 <timburke> right! that weird eventlet issue!
21:35:12 <clayg> is it the GET with swapped frags test?
21:35:13 <rledisez> it's this one: https://review.opendev.org/#/c/704892/2/test/unit/proxy/controllers/test_obj.py
21:35:13 <patchbot> patch 704892 - swift - proxy: stop sending frags to PyECLib with a Queue - 2 patch sets
21:35:18 <rledisez> yes
21:35:35 <clayg> rledisez: I'll take a look tomorrow!  💪
21:35:55 <rledisez> clayg: thx a lot, you're awesome!
21:36:01 <rledisez> (you all are!)
21:36:45 <rledisez> I'll add a comment to show how to reproduce the issue
21:37:53 <rledisez> otherwise, I'm still doing some profiling. I'll start looking at out use of len() (it counts, for real :D) and also i'll try to play with buffer protocol to see if we can save some memory copy
21:38:38 <timburke> nice
21:40:36 <timburke> anybody have strong opinions on metric naming? or experience with fallout from trying to split one metric into several? i'm looking at https://review.opendev.org/#/c/716016/1/swift/common/middleware/s3api/s3api.py in particular...
21:40:37 <patchbot> patch 716016 - swift - s3api: Add stats for s3api requests - 1 patch set
21:41:50 <timburke> i'm trying to judge how important it is for us to get it right the first time, vs needing to do a split by bucket vs key later
21:42:41 <mattoliverau> Was it the object replicator in recon where we wanted to rename some metrics, we're now been doubling up on metrics there for a while.
21:42:58 <mattoliverau> I make them the same a the db replicator.
21:43:08 <rledisez> so, the patch comes from us. we were originally interested in seeing the adoption of s3. but I like the idea of object vs bucket requests
21:43:54 <timburke> rledisez, yeah, the adoption metrics make a lot of sense
21:44:13 <timburke> i can wait for another patchset then
21:46:02 <timburke> all right, i think i'm'a call it
21:46:13 <timburke> thank you all for coming, and thank you for working on swift!
21:46:17 <timburke> #endmeeting