21:00:17 #startmeeting swift 21:00:18 Meeting started Wed Nov 20 21:00:17 2019 UTC and is due to finish in 60 minutes. The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:21 The meeting name has been set to 'swift' 21:00:28 who's here for the swift meeting? 21:00:42 o/ 21:00:51 o/ 21:00:55 o/ 21:00:58 o/ 21:01:19 o/ 21:01:50 i know kota_'s busy... clayg may still join? 21:02:14 apologies, i still haven't updated the agenda since before the summit 21:02:47 there are a few things going on that i'd like to mention though 21:02:58 #topic continuing py2 support 21:02:59 party time 🥳 21:04:05 it sounds like we're basically the only ones wanting to continue supporting py2. i certainly feel like that's the right decision (particularly in light of how recently we added py3 support), but there are likely to be some challenges as everyone else starts dropping support 21:04:34 looks like devstack is switching to py3 by default 21:04:36 #link http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010938.html 21:05:06 which means we need some adjustment of our jobs to continue *actually* testing py2 21:05:10 #link https://review.opendev.org/#/c/695057/ 21:05:11 patch 695057 - swift - Switch py2 DSVM jobs to only run swift under py2 - 1 patch set 21:05:48 bummer! 21:06:00 ...should fix up our dsmv jobs, but there will probably be some other, similar changes that will come along 21:06:51 basically, just a heads-up: you might want to periodically check that the gate tests are actually exercising the environments that we *think* they are 21:07:11 see also: 21:07:13 #link http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010957.html 21:07:42 (which i think is what caused out lower-constraints trouble recently) 21:08:17 #topic stable 21:08:40 i recently requested a couple more stable releases, for stein and rocky 21:08:43 #link https://review.opendev.org/#/c/694854/ 21:08:44 patch 694854 - releases - Swift stable releases - 2 patch sets 21:08:49 just as an FYI 21:08:52 oh nice 21:09:57 but speaking of stable, there have been some interesting conversations on the mailing list about per-project stable cores and who should own that list 21:10:00 #link http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010911.html 21:10:51 basically, "The proposal that I had was that in mind would be for us to let teams self manage their own stable branches." 21:11:03 that makes sense to be honest, I never really understood why there was a seperate team 21:11:32 or rather, why it wasn't cores of project + stable team dealing with backports. 21:12:28 yeah, seems reasonable to me, too. and i think giving project teams that ownership may increase their interest in proposing backports 21:13:13 or, push them to acknowledge that stable branches aren't really a thing that they do. not sure yet which camp swift would fall into ;-P 21:13:31 timburke: you're a backport master! 21:14:33 clayg, it's one of the nice things about a hand-curated changelog! every couple months or so you've got someone looking through the history and thinking about what's noteworthy, how things impact clients, etc. 21:15:07 anyway, just a conversation i thought worth pointing out 21:15:13 handcrafted software 21:15:19 #topic PTG photos 21:15:29 they're up! 21:15:32 #link https://www.dropbox.com/sh/1my6wdtuc1hf58o/AACU49pjWxzFNzcZJgjLG8n1a?dl=0 21:15:48 and specific to swift... 21:15:50 #link https://www.dropbox.com/sh/1my6wdtuc1hf58o/AACU49pjWxzFNzcZJgjLG8n1a?dl=0&preview=Swift.JPG 21:16:28 nice 21:16:37 thanks again to everybody who came, and i look forward to the next time we can all get together :-) 21:17:12 vancover!!! we need mattoliverau 21:17:23 :) 21:17:44 great to see cschwede there! 21:17:47 clayg, mattoliverau's beach house! i bet february's *great* in australia! 21:17:52 ;-) 21:18:06 yeah, middle of summer on the beach.. it can't really be beat :) 21:18:18 that's all i've got -- on to updates! 21:18:32 #topic null namespace & versioning 21:18:42 clayg, tdasilva, how's it going? 21:18:51 great! 21:19:19 swift's new version api + swiftclient is a lot of fun to use 21:19:26 listing versions and all that fun stuff 21:19:41 I'm working on cleaning up the s3api patch 21:19:53 should have all the todos done and tests passing by friday 21:20:05 \o/ 21:20:10 before I sign off for t-day next week I expect they'll have my +2 on them anyway 21:20:37 but, it'll be interesting to see what gaps @tdasilva and @timburke find when they get back from their vactions 🤔 21:20:46 it's always amazing what a fresh set of eyes can do 21:21:04 or even the same eyes - but after they've rested 🤣 21:21:16 new eyes are good too! :) 21:21:39 regardless I'm super happy about what we've built - swift's new versoining mode is a really great feature and it makes putting a solid s3 implementation on top just a delight 21:22:50 mattoliverau, alecuyer, rledisez, seongsoocho: this has been a very SwiftStack-driven set of patches -- do you guys have any concerns about that? would any of you want to be sure to review it before it lands on master? 21:23:31 I'll definitely give em a review (and a play) :) 21:23:46 yay! thanks, mattoliverau 21:23:47 It sounds really good, but yes I need to take the time to actually try it out and read the code! 21:24:06 i'll try to look at it, not that I have any concerns, but mostly to be sure I understand how it works 21:24:21 👍 21:25:15 awesome thanks everyone! 21:25:32 clayg, are there any last lingering questions or design decisions we ought to bring up with everyone? or is it mostly just a matter of polish at this point? 21:26:01 well we added the swift-specific features for restore with PUT?version-id=x 21:26:03 ( I need to take the time to follow up the review. and I also have a interest about that ) 21:26:32 that's a cool trick, and a new API - but it'll all be covered in docs when we're done (and mostly supported in swiftclient) 21:27:02 of course you'll be able to ignore all that noise and just use aws s3api cli tool if that's your thing as well 21:28:14 clayg, right -- because there's also this difference between swift and s3 when doing a version-aware delete of the current version, right? 21:29:16 yeah, the other difference with s3 is applying a version-id to unversioned objects when they're overwritten after enabling versioning 21:29:41 basically those design choices make things work better for the swift api given our underlying implementation 21:30:04 but it's probably fine; because s3's behavior there was a bit akward 21:30:34 however if you REALLY want to destroy the current version AND make the previous version the current versoin we won't do that with one request 21:31:16 ... we could potentially add some api sugar to do that at some point - but it's nice if the client can be explicit 21:32:21 ...which is probably for the best anyway -- since the proxy would need to make multiple back-end requests even if we could make it one client request 21:32:37 YOU BETCHA! 21:32:51 all right 21:32:53 #topic losf 21:33:31 alecuyer, rledisez -- in light of our discussions at the PTG, should i just table this for a while, let us add it back to the agenda if/when it makes sense again? 21:34:14 yes, I think that's right 21:34:36 timburke: I think it still make sense because there is a use case for it. the question is will it match the next use case? 21:34:57 but right now, the dev on losf in OVH is a bit slowing down 21:35:11 so i'm okay with that too :) 21:35:12 i was about to say -- or, we could turn it into a broader discussion about what you've found in trying things with zfs/xfs-with-realtime-device :-) 21:35:18 right 21:35:47 timburke: we can also do that :) 21:35:47 in very short I would say the 2 viable options still in course would be zfs or losf :) 21:35:52 but we are still investigating 21:36:09 I've played with eBPF a bit, it's suprisingly easy to count the VFS calls, but harder to account for it at the block device level. Anyway I'll keep working on this, and trying LOSF/ ZFS etc, and I'll share the results 21:37:57 sounds good 21:38:34 #topic profiling 21:38:55 https://review.opendev.org/#/c/693116/ landed! 21:38:56 patch 693116 - swift - proxy: stop sending chunks to objects with a Queue (MERGED) - 5 patch sets 21:39:05 \o/ 21:39:20 yeah, thx for all the "recheck" ;) 21:39:25 great work on that rledisez 21:39:37 not much profiling this week. i have a patch to implement watchdog, all tests passes except 4, I need to dig why. 21:39:50 after that I have a couple of other small improvement to come 21:40:08 and I though a bit more about replacing MD5 for checksuming, I should write that down on etherpad 21:40:24 nice, look forward to them :) 21:40:46 i think i also saw a couple new cases on the etherpad? same-chunk, where proxy and object servers match chunk sizes 21:41:09 and I'm thinking about etag and the API. the behavior is already a bit "strange" depending on the type of object (raw, SLO, DLO). I'm wondering at some point if we can just "disable" it (from an api point of view) 21:41:23 timburke: yes, if the cunk size match, performance are better 21:44:10 all right, i think that's about it 21:44:17 #topic open discussion 21:44:33 is there anything else to bring up? 21:47:11 all right, let's let mattoliverau and seongsoocho get breakfast :-) 21:47:20 \o/ 21:47:26 * mattoliverau is hungry 21:47:26 thank you all for coming, and thank you for working on swift! 21:48:01 oh! one last thing: in light of thanksgiving week next week (and the fact that i'll be on vacation ;-) let's skip the meeting next week 21:48:14 kk 21:48:21 ok 21:48:21 thanks again! 21:48:23 \o/ 21:48:32 #endmeeting