21:01:08 <notmyname> #startmeeting swift
21:01:09 <openstack> Meeting started Wed Sep 27 21:01:08 2017 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:12 <openstack> The meeting name has been set to 'swift'
21:01:40 <notmyname> who's here for the swift meeting?
21:01:48 <mattoliverau> o/
21:01:58 <kota_> o/
21:01:59 <tdasilva> hi
21:02:11 <acoles> happy triage day
21:02:16 <jungleboyj> @!
21:02:16 <_pewp_> jungleboyj ( ^_^)／
21:02:28 <notmyname> #topic bug triage day
21:02:42 <notmyname> the only topic today is bug triage day
21:02:43 <mathiasb> o/
21:02:51 <notmyname> #link https://etherpad.openstack.org/p/swift-bug-triage-list
21:02:59 <notmyname> #link https://bugs.not.mn/project/swift/bug_trends/None
21:03:23 <notmyname> so how is it going?
21:03:31 <notmyname> I've been in meetings all day
21:03:53 <kota_> me too, in fact.
21:03:56 <notmyname> (speaking of which, a quick summary from the put/post meeting earlier would be nice as the next topic)
21:05:04 <timburke> it goes. i'm currently stuck trying to remove swift from a bug without getting a 503 though
21:05:16 <notmyname> any questions that have come up related to open bugs? anything we need to discuss?
21:05:22 <notmyname> this may be a very short meeting ;-)
21:06:16 <tdasilva> same as timburke...it goes...
21:06:21 <timburke> https://bugs.launchpad.net/swift/+bug/1695273 is reasonably interesting/worth discussing -- should we be more opinionated about what gets counted in our error stats?
21:06:23 <openstack> Launchpad bug 1695273 in OpenStack Object Storage (swift) "Subrequests from ratelimit for /auth/v1.0 considered as proxy-server errors" [Undecided,New]
21:06:23 <notmyname> ok
21:06:25 <mattoliverau> I haven't started yet, as I'm triaging on meeting day
21:07:03 <mattoliverau> But looking at the graphs, do we need track new (or untriaged) bugs
21:07:07 <mattoliverau> I don't see em
21:07:25 <mattoliverau> Or maybe I need to zoom in
21:07:26 <tdasilva> notmyname: I was thinking that maybe it would have been better to have like a goal in mind. 'let's commit to triage 5 bugs today'
21:07:32 <notmyname> mattoliverau: I think tdasilva made some updates to the code. tdasilva can I redeploy it?
21:07:37 <timburke> i still don't even see graphs :-)
21:07:48 <acoles> I got though a few. having the day marked on my calendar definitely forced me to make give some time to it.
21:07:50 <notmyname> timburke: yeah, reload it. sometimes works for me
21:07:59 <tdasilva> notmyname: nothing new to deploy yet, sorry...was just starting to play with it
21:08:16 <tdasilva> mattoliverau: I'd go by the etherpad
21:08:36 <tdasilva> acoles: yeah, me too :)
21:08:38 <notmyname> timburke: IMO about that error, there was another bug about ratelimit + auth and RL+s3, so it may all be related to rl just not checkign the right thing?
21:09:06 <notmyname> tdasilva: acoles: good to hear (about the calendar day prompting you to look at more)
21:09:06 <mattoliverau> Oh yeah, I plan too.. just looking at graphs cause graphs are cool
21:09:18 <acoles> I found myself setting some Wishlist bugs to Confirmed just to get them out of New status. does that make sense? I suppose we might reject a wishlist bug.
21:09:53 <notmyname> acoles: yeah, that sounds fine
21:09:59 <timburke> yeah, there are three parts to it -- i was about to just close it because the first two were better written up as separate (and referenced!) bugs when i noticed the ask about proxy-logging
21:10:08 <notmyname> and yes I can totally imagine rejecting a wishlist bug :-)
21:10:34 <tdasilva> I just rejected a wishlist bug as 'won't fix' :/
21:12:21 <notmyname> ok, doesn't sound like a lot of questions about bug triage...
21:12:25 <notmyname> keep up the good work :-)
21:12:37 <notmyname> #topic put/post meeting summary
21:12:48 <notmyname> zaitcev: would you like to give a summary of this morning's meeting?
21:12:54 <notmyname> tdasilva: do you have the recording link?
21:13:02 <notmyname> (anyone else can give a summary too)
21:13:03 <zaitcev> notmyname: sure
21:13:13 <tdasilva> looking for link
21:14:06 <acoles> is zaitcev  here?
21:14:32 <mattoliverau> Well we said 'sure' so yeah
21:14:36 <mattoliverau> *he
21:14:37 <zaitcev> We considered what was done and found that I didn't realize that our commit protocol had 3 distinct phases. Instead, I only implemented 2, by squishing metadata write and the commit to durable together. So this needs to change.
21:15:30 <tdasilva> #link https://bluejeans.com/s/CG9yI/
21:15:49 <notmyname> https://review.openstack.org/#/c/427911/
21:15:50 <patchbot> patch 427911 - swift - PUT+POST and its development test
21:15:57 <notmyname> #link https://review.openstack.org/#/c/427911/
21:15:58 <patchbot> patch 427911 - swift - PUT+POST and its development test
21:16:22 <zaitcev> Otherwise, there weren't any major concerns raised. Nobody objected to 20-minute timeouts for re-probing servers, or to the protocol detection tricks.
21:17:20 <notmyname> from the high level, this patch zaitcev is working on is very important because it unblocks a few other things going on (clay removing evently, alex doing LOSF, eventually a golang storage server)
21:17:45 <notmyname> this patch means that the object server is back to being "real" http instead of relying on features that we implemented in eventlet's https server
21:17:59 <notmyname> acoles: tdasilva: timburke: anything else to add about the meeting this mroning?
21:18:04 <notmyname> zaitcev: what's the next step?
21:18:29 <zaitcev> Oh, and also! I managed to complain about our unit tests that are so insanely complex that I could not adapt them to the new code, so when you run .unittests on that thing, it just forces old EC.
21:19:12 <tdasilva> notmyname, zaitcev: i think we also need to look at the solution torgomatic had for the linkat path, right?
21:19:22 <notmyname> ah, right
21:19:31 <torgomatic> yeah, I need to get that cleaned up enough that I can post it somewhere without too much shame
21:19:39 <zaitcev> notmyname: I'm going to create PUT+POST+POST that has 3 phases, run "git review', hope I'm not wasting your time with this.
21:20:04 <acoles> zaitcev: you are not wasting time
21:20:09 <zaitcev> oh, yeah, the linkat(2)
21:20:10 <notmyname> not at all
21:20:40 <tdasilva> torgomatic: is this patch still desired as part of this exercise: https://review.openstack.org/#/c/340526/
21:20:40 <patchbot> patch 340526 - swift - Unify Putter and MIMEPutter into a single class.
21:20:44 <acoles> we need PUT->temp file, POST ->non-durable .data file, POST -> durable data file
21:20:55 <clayg> so many verbs!
21:21:03 <acoles> first post carries the metadata, second post is the commit
21:21:26 <zaitcev> acoles: thanks for clarification, that's how I understood the necessary change.
21:21:30 <torgomatic> tdasilva: I mean, I think it's good to have, otherwise crypto or other footer-using things are going to end up still having MIME in their protocol
21:22:45 <timburke> i wonder if we might be able to still use 100-continue to collapse the two POSTs... i don't think we'd need to send any headers with it, then
21:22:56 <zaitcev> I have looked at that unified thing and was indiffirent to it... It does not hurt PUT+POST, although currently it's convenient to use a whole new class (DoublePutter) and flip it over. But it can be done with some kind of argument to .connect() as well.
21:25:25 <clayg> @timburke you just blew my mind!
21:25:45 <clayg> I would expect any request would a body *could* send expect: 100-continue
21:26:19 <notmyname> what's the next step? zaitcev will push a new patch and we review it, expecting it to land? or is there more obvious work to do? (ie are we including all this in the first patch or doing that later?)
21:27:29 <timburke> clayg: and we could just have that body be a 0-byte chunk like what i'm doing in https://review.openstack.org/#/c/476992/
21:27:30 <patchbot> patch 476992 - swift - Make If-None-Match:* work properly with 0-byte PUTs
21:28:11 <acoles> notmyname: we need to address the unit test issue
21:28:20 <notmyname> ok
21:28:33 <clayg> timburke: hrm... 100-continue chunked transfer... yes...
21:29:05 <notmyname> unless we have more logistics or something like that to cover, I think details of implementation could be discussed in -swift (and we can end this one earlier or allow for other things)
21:29:08 <notmyname> #topic open discussion
21:29:14 <notmyname> anything else to bring up this week?
21:29:51 <mattoliverau> I just wanted to thank acoles and timburke  on all the awesome sharding cleanup patches
21:30:03 <timburke> and thanks torgomatic and zaitcev for landing https://review.openstack.org/#/c/506410/ !
21:30:04 <patchbot> patch 506410 - swift - Stop reloading swift.common.utils in test_daemon (MERGED)
21:30:21 <timburke> it'll unblock mattoliverau's https://review.openstack.org/#/c/506002/
21:30:21 <patchbot> patch 506002 - swift (feature/deep) - Use temp db and a rename for set_sharding_state
21:30:45 <acoles> mattoliverau: you did the hard work
21:32:06 <notmyname> tdasilva: can you give a quick summary of the swift3 call we had last week?
21:32:36 <notmyname> notes from the swift3 meeting are at
21:32:37 <notmyname> #link https://etherpad.openstack.org/p/s3api-middleware
21:32:45 <tdasilva> sure, we had another meeting to discuss how we should go about adding the swift3 middleware to swift tree
21:33:13 <tdasilva> we listed some of the patches that should be merged before doing a last release on swift3
21:33:32 <mattoliverau> MbS
21:33:35 <tdasilva> and also came up with a list of work that would need to get done on the feature branch before the new s3api middleware lands on master
21:33:44 <mattoliverau> Sorry that was the toddler on my lap
21:33:49 <tdasilva> it's all on the etherpad ^^^
21:34:15 <kota_> nice tdasilva thanks
21:34:39 <notmyname> anything else going on that needs a status update?
21:34:45 <m_kazuhiro> I think symlink patch #232162 is ready for review and it looks good to me. So please review it.
21:34:45 <patchbot> https://review.openstack.org/#/c/232162/ - swift - Symlink implementation.
21:34:46 <notmyname> I think we covered the big stuff I know of
21:35:32 <tdasilva> yes, please help review symlink patch, i know it's a bit on the fringe of everybody work, but it would be nice if we could finally merge it
21:35:52 <tdasilva> as it would unblock m_kazuhiro tiering work
21:35:52 <mattoliverau> For those of us in Australia.. day light savings changes this weekend (I think)
21:35:59 <notmyname> yeah, unfortunately on the fringe, but definitely something that is needed
21:36:11 <notmyname> mattoliverau: ah, ok. so you'll be one more hour apart
21:36:15 <notmyname> (I think)
21:36:32 <mattoliverau> Yeah, I go forward an hour
21:36:42 <notmyname> oh, you'll be closer then
21:36:44 <mattoliverau> So this will be an hour later
21:36:47 <notmyname> (to CA)
21:36:50 <clayg> just came up in a meeting here a few minutes ago - well more like "tiering" - but symlinks was explicitly called out as an important primitive regardless.
21:36:56 <mattoliverau> Which isn't bad for this meeting :)
21:38:18 <notmyname> I think we're good for this meeting this week :-)
21:38:21 <notmyname> thanks for coming
21:38:29 <notmyname> keep up the good work on bug triaging
21:38:37 <notmyname> and thanks for working on swift
21:38:40 <notmyname> #endmeeting