21:02:15 <timburke> #startmeeting swift
21:02:16 <openstack> Meeting started Wed Sep 25 21:02:15 2019 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:19 <openstack> The meeting name has been set to 'swift'
21:02:24 <timburke> who's here for the swift meeting?
21:02:31 <kota_> o/
21:03:29 <mattoliverau> o/
21:03:32 <rledisez> o/
21:03:42 <alecuyer> o/
21:03:53 <timburke> agenda's at https://wiki.openstack.org/wiki/Meetings/Swift
21:03:59 <tdasilva> hello
21:04:17 <timburke> i've got more stuff ahead of updates than usual, so i'll try to hustle :-)
21:04:27 <timburke> #topic User survey results
21:04:36 <timburke> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009501.html
21:04:59 <timburke> this was actually available last week, but i finally got around to looking at them with some amount of depth
21:05:38 <timburke> we only had a couple swift-specific questions: what features are you using, and a free-form "Other feedback" field
21:06:10 <timburke> we didn't get any free-form comments, but i still saw some interesting things
21:06:28 <timburke> 62 of 342 respondents included feedback about which Swift features they use
21:07:24 <mattoliverau> and... what did they use?
21:07:29 <timburke> but there were an additional 6 who "contribute maintenance resources, such as patches for bug fixes and code reviews on master or stable branches" to Swift without mentioning which Swift features they use
21:07:39 <timburke> top 5 features:
21:07:47 <timburke> S3 compatibility (54)
21:07:51 <timburke> Quotas (35)
21:07:54 <timburke> Object versioning (26)
21:07:58 <timburke> Multi-region clusters (26)
21:08:02 <timburke> Temporary URLs (25)
21:08:26 <kota_> interesting
21:08:32 <timburke> so i feel rather vindicated in the recent focus on S3 versioning ;-)
21:08:47 <mattoliverau> yeah, nice one
21:09:03 <tdasilva> multi-region == 26!!
21:09:28 <timburke> tdasilva, yeah, definitely interesting
21:09:44 <timburke> there were other questions posed (by the TC, i think?) asking about stable branch usage
21:09:52 <timburke> 54 of 62 Swift respondents use stable branches to some degree, with 28 "using only official point releases"
21:10:04 <timburke> ...so i should maybe tag more stable releases
21:10:30 <rledisez> tdasilva: 26 means 26 clusters in 26 regions or 1 cluster/1 ring with 26 "zones/regions" ?
21:11:09 <timburke> 26 of the 62 respondents said they "use" multi-region clusters
21:11:10 <tdasilva> rledisez: i have no idea, i'm hoping it's 26 different people, meaning 26 different clusters
21:11:20 <rledisez> ah, ok :D
21:11:37 <rledisez> i was wondering who would do a 26-regions ring ;)
21:11:51 <timburke> O.O
21:12:19 <timburke> anyway, thought i would share. i'll make sure i get the full tally of feature usage up somewhere for the curious
21:12:32 <timburke> (or you can grab the dataset yourself and take a look ;-)
21:12:33 <tdasilva> timburke: i'd argue we should almost do a stable branch tag almost every time we do a stable backport (or a string of backports)
21:12:50 <timburke> yeah... i kinda agree
21:12:51 <tdasilva> like if there's nothing else left in the pipeline, tag
21:13:24 <mattoliverau> or maybe at least every time we do a release we should see if there has been any backports and if so.. tag
21:13:39 <timburke> i think the biggest hurdle has been a sense that "oh, if i'm proposing a tag, i should probably see what other bug fixes maybe ought to get backported..."
21:14:41 <timburke> mattoliverau, definitely. one of the nice things about hand-curating the release notes is that i get a whole bunch of patches and their impacts loaded into my head anyway, which can then be used on my previous concern
21:15:12 <timburke> #topic Vancouver
21:15:31 <mattoliverau> \o/ back to YVR
21:15:49 <timburke> i know we haven't even gotten to Shanghai yet, but apparently we're going back to Vancouver for the next OpenStack event in June
21:15:52 <timburke> #link http://lists.openstack.org/pipermail/foundation/2019-September/002794.html
21:15:53 <zaitcev> What's in Vancouver? Also, which Vancouver?
21:16:02 <kota_> wow
21:16:09 <zaitcev> reading now
21:16:23 * rledisez loves Vancouver
21:16:38 <timburke> rledisez, and your flight got so much shorter!
21:16:49 <mattoliverau> lol
21:16:50 <rledisez> yeah, makes it even better :)
21:17:23 <timburke> you all now know as much as me about all this :-) i'm sure we'll find out more in the coming months
21:17:42 <timburke> #topic Shanghai
21:18:00 <timburke> just a quick reminder again to put topic on the etherpad
21:18:03 <timburke> #link https://etherpad.openstack.org/p/swift-ptg-shanghai
21:18:10 <timburke> (i need to do it, too)
21:18:21 <timburke> #topic train release
21:18:44 <timburke> so within the next week or so, i'd like to tag a 2.23.0
21:19:16 <timburke> i updated the priority reviews wiki to highlight a few patches i'd like to get in if we can
21:19:18 <timburke> #link https://wiki.openstack.org/wiki/Swift/PriorityReviews
21:20:05 <timburke> the top two in particular would be good -- and one of them is actually a bug that still needs a patch
21:21:12 <timburke> specifically, those have to to with our new py3 support -- and one of them is a (now public) security bug
21:22:11 <timburke> if you know of any other patches that ought to get in, feel free to update the wiki. i'll try to get a patch up for https://bugs.launchpad.net/swift/+bug/1844368 in the next couple days
21:22:11 <openstack> Launchpad bug 1844368 in OpenStack Object Storage (swift) "fallocate_reserve cannot be specified as a percentage running under python3" [High,Confirmed]
21:22:50 <zaitcev> If anyone knows anything about eventlet monkey-patching, there
21:23:00 <timburke> mattoliverau or zaitcev, you've done a good bit with py3 -- would you be able to review https://review.opendev.org/#/c/684041/ ?
21:23:01 <zaitcev> 's also this: https://review.opendev.org/684380
21:23:43 <zaitcev> timburke: will do
21:25:31 <timburke> thanks. and i can try to take a look at the triple-o patch -- sounds kinda like the issue i hit in https://review.opendev.org/#/c/675227/ where the module that i wanted patched was imported before i realized that it would be
21:26:02 <timburke> ok, updates!
21:26:10 <timburke> #topic versioning
21:26:12 <zaitcev> As you can see, it is not a review in Swift. The story is, Swift requires eventlet 0.25 for py3. So, I made RDO update the required eventlet. Result is, TripleO fell apart, because the module git has issues with eventlet. It's a mad word, but if anyone can understand what happend, they could add +1.
21:26:59 <timburke> tdasilva, what's the state of the world?
21:27:49 <tdasilva> with the new object versioning patch per se, we've been making progress adding some unit and functional tests
21:28:42 <tdasilva> there are still some corner cases to discuss the design about. e.g., how to handle error scnearios of creating versions container, how to handle versions and overwrites when versioning is suspended
21:29:39 <tdasilva> but it's coming along. For now we are also punting on the naming scheme, as we have started discussion on the null character piece
21:30:02 <clayg> did i miss the whole thing?
21:30:28 <tdasilva> clayg: nope
21:30:34 <timburke> clayg, i think you're right on time :-)
21:31:24 <tdasilva> timburke: so we've made progress, but there's still quite a bit of work to do :)
21:31:58 <timburke> i know we've got some etherpads for both versioning and the null-byte ideas
21:32:01 <timburke> #link https://etherpad.openstack.org/p/swift-object-versioning
21:32:02 <tdasilva> if folks can keep an eye and contribute to both the discussion on the etherpad and the patches listed here, it would be super helpful: https://etherpad.openstack.org/p/swift-object-versioning
21:32:08 <timburke> #link https://etherpad.openstack.org/p/swift-null-namespace
21:32:56 <mattoliverau> oh i didn't realise there was a null namespace one. I'll read it today
21:33:15 <timburke> mattoliverau, i think clayg added it today ;-)
21:33:31 <clayg> yeah that's new fresh off the presses
21:33:34 <mattoliverau> oh, well then I was alseep anyway :P
21:33:40 <kota_> interesting, the null namespace idea
21:34:02 <tdasilva> kota_: it's revolutionary! :D
21:34:30 <clayg> 🤣
21:35:03 <kota_> it seems like similar idea s3api (swift3) uses `+` for versioning namespace that character can not be used by users.
21:35:09 <timburke> clayg, tdasilva: anything in particular you'd like input on this week?
21:35:20 <timburke> kota_, i think that may be where we got the idea :D
21:35:48 <kota_> +1
21:35:48 <clayg> kota_: yes, lots of s3 features and s3api implementation rely on resources the user can't access except through approved apis!
21:36:55 <clayg> tdasilva: do we have the versioning api draft anywhere?
21:37:00 <clayg> something that might eventually become the docs?
21:37:15 <tdasilva> timburke: yeah, i think in terms of order, the null character would come first?? it would probably be good to get a good design on that
21:37:30 <tdasilva> clayg: no yet, /me needs to get started on that :(
21:37:57 <clayg> tdasilva: right, everyone please read and comment on the null-namespace etherpad - I'm going to be implementing what's in there so expect to be doing some early review stuff soon
21:38:26 <timburke> 👍
21:38:28 <clayg> tdasilva: i was thinking more fast/dirty wiki style for folks to get an idea - but... I guess we have the s3 api for that 🙄
21:39:03 <tdasilva> clayg: yeah, I was thinking about adding to the etherpad to begin with, it makes for editing very easy
21:39:07 <tdasilva> by anyone
21:39:16 <clayg> tdasilva: I had an idea about versioned_writes - that maybe we call the new mode "object versioning" and the old one was *truly* "just" versioned_writes (i.e. no versioned reads, or restore, or listing)
21:39:36 <clayg> might help us avoid calling the "object versioning" feature "new versioned writes"
21:40:02 <clayg> or maybe.. there's the "object versions api" and "legacy versioned writes" or something - idk - i get hung up on names
21:40:18 <clayg> tdasilva: hell yeah, etherpad it up!
21:40:50 <timburke> FWIW, i feel like the S3 docs aren't always sufficient -- exploratory things like tdasilva's http://paste.openstack.org/show/779176/ are certainly useful, too
21:41:40 <tdasilva> clayg: i've been really scratching my head on naming, open to suggestions
21:42:10 <tdasilva> timburke: yeah, also found out from testing that s3 doesn't allow POSTing to older versions, I haven't seen that documented
21:42:26 <timburke> clayg, would it be worth breaking out https://review.opendev.org/#/c/682953/1/test/s3api/test_versioning.py to its own patch as a lace for us to document what AWS does?
21:42:33 <timburke> tdasilva, GTK
21:43:16 <clayg> tdasilva: yeah i breifly let myself think that we might back off on allowing POST to static links via versioning and instead stick with our re-direct behavior (i.e. allow POST key?version=)
21:43:59 <timburke> all right, i still want to check in on other endeavors -- maybe we can continue this in -swift
21:44:04 <timburke> #topic lots of small files
21:44:08 <clayg> timburke: I guess that'd be ok just for organization - I don't think we need/want s3api tests that fail against swift merged to master?
21:44:21 <timburke> clayg, fair enough
21:44:23 <timburke> alecuyer, i saw another patch this morning!
21:44:44 <timburke> an updated version of https://review.opendev.org/#/c/666378/
21:45:10 <alecuyer> yes ! I'm getting to the patches that were pending,
21:45:15 <timburke> have you had a chance to sort out the bugs found when trying to deploy to prod?
21:45:22 <alecuyer> I've updated it to work with HTTP
21:45:38 <alecuyer> so about the bug, the good news, it's unrelated to the "rpc over http" patch
21:45:55 <timburke> 👍 (on both messages)
21:46:17 <alecuyer> we quickly tacked on a patch to bring back the hashes.pkl - and hum the "hang" was actually that the algorithm cost would go up with the square of the suffixes below the partition
21:46:31 <alecuyer> so, hm, that was quickly reverted
21:46:40 <timburke> eep!
21:46:59 <alecuyer> and I'll look at it later. But, no issues found with the HTTP patch itself
21:47:58 <timburke> is there anything we can be helping with? i'll look at the py3 failures
21:48:51 <alecuyer> thanks ! haven't looked at it yet but I will. So yes that would be great if you could take a look at the patch
21:49:15 <alecuyer> then I'll go back to the other pending patches (they are smaller than this one)
21:49:34 <timburke> sounds good, thanks!
21:49:48 <timburke> #topic sharding
21:50:04 <timburke> lots of cleave-context cleanup!
21:50:51 <mattoliverau> lol, yeah, I felt guilty that we weren't using an existing last-modified timestamp and adding a new one which would be annoyting for NM and needless storage.. So fixed that.
21:51:09 <mattoliverau> Then clayg went and cleaned it up even further!
21:51:16 <timburke> thanks for that, i think it's a bunch better :-)
21:51:29 <timburke> mattoliverau, is there anything else there that you want to bring up, or do i just need to get to reviewing more patches? ;-)
21:51:36 <clayg> minor stuff, paper cuts
21:51:47 <clayg> is there more to review!?  😬
21:51:55 <timburke> always :D
21:52:09 <timburke> https://review.opendev.org/#/c/675820/ for the empty handoff problem
21:52:26 <timburke> https://review.opendev.org/#/c/675014/ to latch stats reporting
21:52:26 <mattoliverau> nope, nothing to bring up. but reviews welcome. I'll review timburke's sharding patches
21:52:55 <timburke> and of course, the autosharder chain: https://review.opendev.org/#/c/667030/ https://review.opendev.org/#/c/667579/
21:53:07 <timburke> #topic open discussion
21:53:17 <timburke> anything else people would like to bring up?
21:53:51 <zaitcev> Not me
21:54:02 <kota_> not
21:55:07 <timburke> one thing i thought of -- the last time we thought much about our current meeting time, there were more of us in SF -- does this time slot still work well for people?
21:56:15 <mattoliverau> daylight savings changes in a few weeks for me then it'lll be 8am.. a much more civilised time :P
21:56:58 <timburke> something to think about, anyway. it's hard with the spacing of US, Europe, and Japan/Australia
21:57:02 <alecuyer> I'm fine with the time - similar to mattoliverau, in winter time it'll be 10pm vs 11 :)
21:57:27 <timburke> on that note, let's let alecuyer go to bed ;-)
21:57:38 <timburke> thank you all for coming, and thank you for working on Swift!
21:57:42 <timburke> #endmeeting