21:00:17 <timburke> #startmeeting swift
21:00:18 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:21 <openstack> The meeting name has been set to 'swift'
21:00:28 <timburke> who's here for the swift meeting?
21:00:42 <mattoliverau> o/
21:00:51 <tdasilva> o/
21:00:55 <alecuyer> o/
21:00:58 <seongsoocho> o/
21:01:19 <rledisez> o/
21:01:50 <timburke> i know kota_'s busy... clayg may still join?
21:02:14 <timburke> apologies, i still haven't updated the agenda since before the summit
21:02:47 <timburke> there are a few things going on that i'd like to mention though
21:02:58 <timburke> #topic continuing py2 support
21:02:59 <clayg> party time 🥳
21:04:05 <timburke> 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 <timburke> looks like devstack is switching to py3 by default
21:04:36 <timburke> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010938.html
21:05:06 <timburke> which means we need some adjustment of our jobs to continue *actually* testing py2
21:05:10 <timburke> #link https://review.opendev.org/#/c/695057/
21:05:11 <patchbot> patch 695057 - swift - Switch py2 DSVM jobs to only run swift under py2 - 1 patch set
21:05:48 <clayg> bummer!
21:06:00 <timburke> ...should fix up our dsmv jobs, but there will probably be some other, similar changes that will come along
21:06:51 <timburke> 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 <timburke> see also:
21:07:13 <timburke> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010957.html
21:07:42 <timburke> (which i think is what caused out lower-constraints trouble recently)
21:08:17 <timburke> #topic stable
21:08:40 <timburke> i recently requested a couple more stable releases, for stein and rocky
21:08:43 <timburke> #link https://review.opendev.org/#/c/694854/
21:08:44 <patchbot> patch 694854 - releases - Swift stable releases - 2 patch sets
21:08:49 <timburke> just as an FYI
21:08:52 <mattoliverau> oh nice
21:09:57 <timburke> 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 <timburke> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010911.html
21:10:51 <timburke> 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 <mattoliverau> that makes sense to be honest, I never really understood why there was a seperate team
21:11:32 <mattoliverau> or rather, why it wasn't cores of project + stable team dealing with backports.
21:12:28 <timburke> yeah, seems reasonable to me, too. and i think giving project teams that ownership may increase their interest in proposing backports
21:13:13 <timburke> 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 <clayg> timburke: you're a backport master!
21:14:33 <timburke> 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 <timburke> anyway, just a conversation i thought worth pointing out
21:15:13 <clayg> handcrafted software
21:15:19 <timburke> #topic PTG photos
21:15:29 <timburke> they're up!
21:15:32 <timburke> #link https://www.dropbox.com/sh/1my6wdtuc1hf58o/AACU49pjWxzFNzcZJgjLG8n1a?dl=0
21:15:48 <timburke> and specific to swift...
21:15:50 <timburke> #link https://www.dropbox.com/sh/1my6wdtuc1hf58o/AACU49pjWxzFNzcZJgjLG8n1a?dl=0&preview=Swift.JPG
21:16:28 <mattoliverau> nice
21:16:37 <timburke> thanks again to everybody who came, and i look forward to the next time we can all get together :-)
21:17:12 <clayg> vancover!!!  we need mattoliverau
21:17:23 <mattoliverau> :)
21:17:44 <mattoliverau> great to see cschwede there!
21:17:47 <timburke> clayg, mattoliverau's beach house! i bet february's *great* in australia!
21:17:52 <timburke> ;-)
21:18:06 <mattoliverau> yeah, middle of summer on the beach.. it can't really be beat :)
21:18:18 <timburke> that's all i've got -- on to updates!
21:18:32 <timburke> #topic null namespace & versioning
21:18:42 <timburke> clayg, tdasilva, how's it going?
21:18:51 <clayg> great!
21:19:19 <clayg> swift's new version api + swiftclient is a lot of fun to use
21:19:26 <clayg> listing versions and all that fun stuff
21:19:41 <clayg> I'm working on cleaning up the s3api patch
21:19:53 <clayg> should have all the todos done and tests passing by friday
21:20:05 <timburke> \o/
21:20:10 <clayg> before I sign off for t-day next week I expect they'll have my +2 on them anyway
21:20:37 <clayg> but, it'll be interesting to see what gaps @tdasilva and @timburke find when they get back from their vactions 🤔
21:20:46 <clayg> it's always amazing what a fresh set of eyes can do
21:21:04 <clayg> or even the same eyes - but after they've rested 🤣
21:21:16 <tdasilva> new eyes are good too! :)
21:21:39 <clayg> 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 <timburke> 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 <mattoliverau> I'll definitely give em a review (and a play) :)
21:23:46 <timburke> yay! thanks, mattoliverau
21:23:47 <alecuyer> It sounds really good, but yes I need to take the time to actually try it out and read the code!
21:24:06 <rledisez> 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 <timburke> 👍
21:25:15 <clayg> awesome thanks everyone!
21:25:32 <timburke> 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 <clayg> well we added the swift-specific features for restore with PUT?version-id=x
21:26:03 <seongsoocho> ( I need to take the time to follow up the review.  and I also have a interest about that )
21:26:32 <clayg> 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 <clayg> 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 <timburke> 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 <clayg> yeah, the other difference with s3 is applying a version-id to unversioned objects when they're overwritten after enabling versioning
21:29:41 <clayg> basically those design choices make things work better for the swift api given our underlying implementation
21:30:04 <clayg> but it's probably fine; because s3's behavior there was a bit akward
21:30:34 <clayg> 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 <clayg> ... 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 <timburke> ...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 <clayg> YOU BETCHA!
21:32:51 <timburke> all right
21:32:53 <timburke> #topic losf
21:33:31 <timburke> 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 <alecuyer> yes, I think that's right
21:34:36 <rledisez> 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 <rledisez> but right now, the dev on losf in OVH is a bit slowing down
21:35:11 <rledisez> so i'm okay with that too :)
21:35:12 <timburke> 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 <alecuyer> right
21:35:47 <rledisez> timburke: we can also do that :)
21:35:47 <rledisez> in very short I would say the 2 viable options still in course would be zfs or losf :)
21:35:52 <rledisez> but we are still investigating
21:36:09 <alecuyer> 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 <timburke> sounds good
21:38:34 <timburke> #topic profiling
21:38:55 <timburke> https://review.opendev.org/#/c/693116/ landed!
21:38:56 <patchbot> patch 693116 - swift - proxy: stop sending chunks to objects with a Queue (MERGED) - 5 patch sets
21:39:05 <mattoliverau> \o/
21:39:20 <rledisez> yeah, thx for all the "recheck" ;)
21:39:25 <mattoliverau> great work on that rledisez
21:39:37 <rledisez> 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 <rledisez> after that I have a couple of other small improvement to come
21:40:08 <rledisez> and I though a bit more about replacing MD5 for checksuming, I should write that down on etherpad
21:40:24 <mattoliverau> nice, look forward to them :)
21:40:46 <timburke> 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 <rledisez> 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 <rledisez> timburke: yes, if the cunk size match, performance are better
21:44:10 <timburke> all right, i think that's about it
21:44:17 <timburke> #topic open discussion
21:44:33 <timburke> is there anything else to bring up?
21:47:11 <timburke> all right, let's let mattoliverau and seongsoocho get breakfast :-)
21:47:20 <mattoliverau> \o/
21:47:26 * mattoliverau is hungry
21:47:26 <timburke> thank you all for coming, and thank you for working on swift!
21:48:01 <timburke> 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 <mattoliverau> kk
21:48:21 <rledisez> ok
21:48:21 <timburke> thanks again!
21:48:23 <seongsoocho> \o/
21:48:32 <timburke> #endmeeting