21:00:24 <notmyname> #startmeeting swift
21:00:28 <openstack> Meeting started Wed Jan  6 21:00:24 2016 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:31 <openstack> The meeting name has been set to 'swift'
21:00:37 <notmyname> hello, everyone. who's here for the swift meeting?
21:00:41 <mattoliverau> o/
21:00:44 <jlhinson> o/
21:00:44 <Zyric_> Hello
21:00:44 <minwoob_> o/
21:00:44 <kota_> hello
21:00:45 <Guest56516> o/
21:00:45 <joeljwright> hello
21:00:46 <pdardeau> o/
21:00:46 <acoles> hi
21:00:46 <m_kazuhiro> o/
21:00:48 <blmartin> o/
21:00:50 <cschwede> o/
21:00:51 <jrichli> hello
21:00:53 <eranrom> hi
21:00:56 <redbo> yo
21:01:09 <notmyname> Guest56516: ho?
21:01:18 <Guest56516> yep
21:01:29 <wbhuber> hi
21:01:34 <notmyname> great to see everyone!
21:01:39 <hurricanerix> \o/
21:01:56 <mattoliverau> hurricanerix seems excited
21:02:02 <notmyname> it's been a while since we've met. I hope your 2015 ended well
21:02:19 <notmyname> mattoliverau: why wouldn't he be? isn't this your week's high point? it's swift team meeting time!
21:02:20 <wbhuber> it did.  it got us here. :)
21:02:21 <hurricanerix> mattoliverau: i am always excited!
21:02:45 <minwoob_> +1
21:02:46 <mattoliverau> true, though I'n under cafeinated for this time of the morning
21:03:09 <notmyname> I was out for two weeks, so I'm still catching up and remembering all the stuff going on :-)
21:03:16 <mattoliverau> +1
21:03:26 <notmyname> a couple of things to note
21:03:50 <notmyname> first, sometime in the last 2 weeks, we hit 500 total contributors to swift (unique patch authors + reviewers)
21:03:54 <cutforth> hello
21:03:55 <notmyname> that's really cool!
21:04:07 <notmyname> graph at http://d.not.mn/total_contribs.png
21:04:17 <kota_> great!
21:04:23 <wbhuber> Impressive!
21:04:27 <joeljwright> :)
21:05:17 <notmyname> the other thing is I took some time this mornign to update the review dashboard
21:05:32 <notmyname> new features from the new gerrit give us some more functionality
21:05:41 <notmyname> https://goo.gl/mtEv1C
21:05:46 <mattoliverau> oh really
21:05:51 <notmyname> the biggest change is the "small things" section
21:06:02 <notmyname> that's 10 patches that are less than 10 lines each
21:06:17 <mattoliverau> ahh nice
21:06:21 <torgomatic> ahoy
21:06:40 * acoles is busy breaking his patches down into smaller ones
21:06:42 <notmyname> I hope maybe we can use that to quickly close them. like if you've got a few minutes before a meeting and can do something small
21:06:44 <notmyname> lol
21:06:48 <cschwede> so we split our patches in subsets of 9LOC, and they will merged semi-automatically?
21:06:57 <notmyname> cschwede: exactly!
21:07:01 <cschwede> great!
21:07:36 <notmyname> i limited it to 10. there's soemthing like 60 or 70 that are that size
21:07:53 <acoles> notmyname: i am glad to see the priority reviews are still at the top
21:08:00 <notmyname> the query is "delta:<=10
21:08:04 <notmyname> "
21:08:22 <notmyname> yeah, a couple of other changes there
21:08:27 <joeljwright> nice to see swiftclient in there too
21:08:28 <cschwede> notmyname: that dashboard looks good!
21:08:29 <joeljwright> :)
21:08:31 <notmyname> I filtered out all the ones that have a merge conflict
21:08:37 <notmyname> joeljwright: it's always been there ;-)
21:08:42 <joeljwright> hiding
21:09:19 <notmyname> if you want to see the definitions, I proposed them upstream at https://review.openstack.org/#/c/264315/
21:10:03 <notmyname> this is in line with the bigger-picture stuff I'm working on
21:10:20 <notmyname> we've got a lot going on. lots of people working on lots of different stuff
21:10:41 <notmyname> but unlike eg storage policies or erasure codes, there's not this One Big Thing (tm) that everyone is doing
21:11:13 <notmyname> the closes we have now is the crypto work, but it's not got as much attention from everyone, honestly
21:11:43 <notmyname> so the thing I'm working on, in general, is to help us all understand the things being done and tie it together
21:12:11 <notmyname> I've got a couple of other things that I'm working on, and I hope they pan out and I can share them soon
21:12:17 <notmyname> but, I need your help :-)
21:12:51 <notmyname> to know what's going on, what you think is important, and overall how we're moving swift forward
21:13:33 <cschwede> where/how do we share our bits of interest?
21:13:45 <cschwede> notmyname: send a mail to you?
21:14:13 <notmyname> that would be great for long-form stuff. also IRC (public or pm) is fine
21:14:29 <notmyname> I'd be happy to call you too. :-)
21:14:42 <notmyname> so that's where my head is recently. I hope some minor changes (like the "small things" dashboard section) can help us keep momentum going on all the upstream work and tie it together
21:15:34 <notmyname> any thoughts, questions, or comments about any of that?
21:16:02 <notmyname> oh, and I think all of you should have my email, but it's me@not.mn if you don't
21:16:13 <cschwede> good idea! more during the call ;)
21:17:12 <mattoliverau> Well I think the small things is a great idea.
21:17:25 <notmyname> the hackathon is coming up. I think we can open up the registrations publicly next week
21:17:31 <mattoliverau> as for talking, I think you should fly down here so we can talk in person.. maybe next month :P
21:17:36 <acoles> notmyname: as well as the small things momentum, we need to not lose sight of the long running "big items"
21:17:38 <notmyname> mattoliverau: great idea ;-)
21:17:53 <notmyname> acoles: of course! and that's the trick, right? :-)
21:17:56 <acoles> notmyname: so i suggest you keep prodding us on those :)
21:18:05 <notmyname> acoles: ok. will do :-)
21:18:06 <mattoliverau> +1
21:18:11 <notmyname> acoles: how's fast-post coming? ;-)
21:18:18 <mattoliverau> lol
21:18:20 <acoles> oh boy
21:18:22 <notmyname> lol
21:18:58 <notmyname> ok, so acoles (when he's not doing fast-post) has got a cool hotel room block for us and is working on good evening stuff one night
21:18:58 <acoles> notmyname: i was thiniking sharding, concurrent gets....
21:19:07 <notmyname> acoles: that's all mattoliverau
21:19:17 <acoles> yeah but we have to review it
21:19:42 * acoles is pointing at self
21:20:00 <eranrom> :)
21:20:16 <mattoliverau> umm. yeah... :P
21:20:19 <acoles> notmyname: all: i should have hotel info out this week. holidays held things up.
21:20:49 <notmyname> oh, kinda on the same general topic... be thinking about the specs. how's it working for you now? what should change (if anything)?
21:21:01 <notmyname> I don't want to discuss now, but it would be a good hackathon topic, I think
21:21:23 <notmyname> we've been using them for about a year or so now. so it's good to see if it's still valuable or not
21:21:38 <mattoliverau> acoles: do you have one of those remote virtual robot things and I can control from here? ;)
21:21:43 <notmyname> so be thinking about it. and if you don't like something, then what you'd change or do differently
21:22:12 <acoles> mattoliverau: sock puppet? ;)
21:22:19 <notmyname> so on to the meeting agenda stuff...
21:22:33 <mattoliverau> a mattoliverau sock puppet would be awesome
21:22:41 <notmyname> because of the holidays I don't have any particular patches to highlight. other than just "go review the starred ones"
21:23:00 <notmyname> but there are a couple of things that have been added to the agenda
21:23:18 <notmyname> eranrom: because of timezones, let's start with the bug you added
21:23:28 <notmyname> #topic bug 1419901
21:23:30 <openstack> bug 1419901 in OpenStack Object Storage (swift) "container-sync checks invalid ClientException" [Undecided,In progress] https://launchpad.net/bugs/1419901 - Assigned to Eran Rom (eranr)
21:23:32 <eranrom> Thanks!
21:23:43 <notmyname> eranrom: what's up? what do you want to discuss about it?
21:24:02 <eranrom> Well, for us (IBM) its kind o critical bug so as to deploy in production
21:24:15 <eranrom> although > 10 LOC still a small patch
21:24:41 <notmyname> ah, ok. important bug. breaking things. you have a patch. needs reviews
21:24:54 <notmyname> patch 260204
21:24:55 <patchbot> notmyname: https://review.openstack.org/#/c/260204/ - Container-Sync to check the right client exception
21:25:19 <notmyname> eranrom: is that about right?
21:25:33 <eranrom> right. so would love to see it also in 2.5.1. BTW  thanks a lot to acoles and mattoliverau for reviewig the other containr sync stuff
21:25:50 <jrichli> +1
21:25:54 <notmyname> eranrom: ah? as a backport? or just "in the next release"?
21:26:13 <eranrom> next release. BTW - do we know when it will happen (next release)
21:26:20 <notmyname> asap
21:26:25 <eranrom> :-)
21:26:35 <Guest56516> is it simular with patch 256306?
21:26:36 <patchbot> Guest56516: https://review.openstack.org/#/c/256306/ - Fix ClientException handling in Container Sync
21:27:57 <eranrom> apparently yes :-)
21:28:19 <eranrom> Only I made the change in container sync and 256306 fixes this in SimpleClient
21:28:36 <notmyname> Guest56516: (ho) eranrom it would be great for the two of you to mutually co-review and see if the patch needs to be combined or not
21:29:01 <eranrom> sure
21:29:06 <Guest56516> notmyname, eranrom: sure.
21:29:09 <notmyname> thanks
21:29:24 <acoles> i added a link to https://review.openstack.org/#/c/256306/ on the bug report
21:29:32 <notmyname> eranrom: I starred your patch, too.
21:29:34 <notmyname> acoles: thanks
21:29:38 <eranrom> thanks!
21:30:23 <notmyname> and bug marked as critical so it will be noticed before a release. I'd like to see it included too
21:30:40 <notmyname> ho: yay. thanks
21:30:46 <notmyname> for the nick change ;-)
21:30:59 <notmyname> eranrom: anything else there?
21:31:06 <eranrom> notmyname: great, thanks!
21:31:09 <eranrom> no
21:31:12 <notmyname> ok
21:31:13 <acoles> come back ho!
21:31:16 <Guest36234> notmyname: sorry for it.
21:31:26 <notmyname> #topic PUT/COPY with range
21:31:35 <notmyname> kota_: this is one you added to the agenda
21:31:36 <kota_> my turn
21:31:43 <kota_> yes
21:31:43 <notmyname> I think I saw some IRC scrollback about this
21:31:44 <notmyname> what's up?
21:32:01 <kota_> during i was reviewing a patch, i found that
21:32:02 <kota_> so
21:32:41 <kota_> here, i'd like to talk on "PUT with X-Copy-From" (not COPY) to clarify my description.
21:32:52 <notmyname> ok
21:33:16 <kota_> at first, currently swift *can* work with PUT X-Copy-From with Range header
21:33:30 <notmyname> right
21:33:33 <kota_> to make a partial copied object
21:33:55 <notmyname> since that gets passed to the backend GET and the response is the body of the new object
21:34:05 <kota_> however i was wondering the "Range" should be on GET, semantically it suggests the range to retrieve the object.
21:34:22 <kota_> and i found the RFC about that
21:34:33 <notmyname> #link https://tools.ietf.org/html/rfc7233
21:34:34 <kota_> at RFC7233
21:34:36 <kota_> yes
21:34:41 <kota_> at section 3.1
21:35:16 <notmyname> hmm
21:35:25 <kota_> it looks to violate the RFC and no docs in Swift api.
21:35:55 <notmyname> ok
21:36:00 <kota_> either is fine, to keep current or do something but i'd like to confirm opinions from swifters.
21:36:10 <notmyname> you had 2 or 3 options in the agenda proposed
21:36:10 <mattoliverau> But a PUT does ignore the Range header, so that's fine right?
21:36:16 <notmyname> mattoliverau: yeah
21:36:16 <kota_> yes
21:36:50 <notmyname> option 1: keep current behavior and update docs
21:36:52 <kota_> if someone already use it and be hurt with change, we should keep current behavior like quoted etag, i think
21:37:18 <notmyname> option 2: disallow/ignore range on non-GET and support the same functionality a different way (query param?)
21:37:27 <kota_> if so, i just push a patch to update docs, yes swift support this semantics.
21:37:32 <kota_> and next is
21:38:03 <kota_> to make swift to ignore the Range header at PUT request acorrding to RFC
21:38:31 <kota_> and make a new header (e.g. X-Copy-Range?) to support this functionality.
21:39:06 <notmyname> my vote would be for option1. keep current behavior and update the docs to show that we support it
21:39:24 <jrichli> +1
21:39:30 <mattoliverau> So a COPY comes in, it becomes a GET and PUT, the range header is not ignored in the GET (correct) and _is_ ignored in the PUT (correct) so I think only docs need to change if they (the docs) aren't correct.
21:39:35 <acoles> hmmm, so does "ignore" allow for passing the header on to the GET request, or does "ignore" strictly mean discarding it?
21:39:53 <acoles> mattoliverau: yes, same as I am thinking
21:40:15 <acoles> notmyname: +1, leave as is and document
21:40:19 <mattoliverau> I think ignore means ignore the header is there, like any other X-header that swift doesn't know about
21:40:41 <joeljwright> +1 for that interpretation of 'ignore'
21:40:53 <acoles> mattoliverau: so the only "server" that does not ignore it is object server handling a GET
21:41:00 <jrichli> I would think the spirit of the RFC is referring to the client interface only: they used PUT, and a range header at the same time.  regardless of how the server implements the request
21:41:18 <notmyname> while I agree with your conclusion, my reading of the spec is that the header doesn't affect the result and we're in violation of it
21:41:34 <notmyname> (and I'm ok with that)
21:42:18 <jrichli> +1
21:42:21 <notmyname> several people want to keep current behavior. anyone want to argue for dropping current behavior?
21:42:28 <notmyname> kota_: what do you want to do?
21:42:40 <mattoliverau> The header doesn't, the GET gets the data, the PUT is ignoring the header and placing what the GET is giving it.. but sure. either way I vote #1 :)
21:43:08 <kota_> tbh, it would be good to change behavior but it's ok to keep current one.
21:43:34 <acoles> notmyname: i see your point re modifying the result.
21:43:35 <timburke> i'd like to note that the behavior when multiple ranges are specified is...unlikely to be what a client actually wants. we store the multipart MIME doc (!) that's returned, which feels like a transport detail, rather than the concatenation of the ranges
21:44:10 <notmyname> timburke: oh yeah. I think that's ugly too
21:44:13 <mattoliverau> that's sure multi range is a different kettle of fish
21:44:23 <torgomatic> let's not open that kettle of worms
21:44:27 <mattoliverau> s/sure/true/
21:44:46 <notmyname> we can dodge it with sloranges
21:44:47 <jrichli> torgomatic: but we haven't even mentioned mixing large objects in there yet!
21:45:11 <timburke> yup. just pointing out that we may need to change the implementation somewhat *anyway*
21:45:36 <notmyname> what if I do a fast-post with multi-ranges and it references other large objects? in an encrypted cluster?
21:45:39 <mattoliverau> or in the COPY middleware.. when that's done
21:45:46 <jrichli> ugh ...
21:45:49 <notmyname> heh
21:45:53 <mattoliverau> lol
21:46:00 <kota_> yeah
21:46:08 <notmyname> yeah, copy middleware. that's one of those other big things acoles is talking about :-)
21:46:18 <acoles> notmyname: depends on backend latency ;)
21:46:23 <mattoliverau> notmyname: nice loop back :)
21:46:27 <notmyname> acoles: yeah! to tape!
21:46:40 <notmyname> so are we in agreement for now? we keep current behavior but we need docs for it
21:46:46 <acoles> notmyname: lets notify some other service
21:46:50 <mattoliverau> +1
21:47:13 <mattoliverau> and tdasilva can look at fixing multi-range in the COPY middleware :P
21:47:20 <kota_> ok, i will make a patch to update docs :)
21:47:21 <notmyname> #agreed keep current behavior but add docs
21:47:24 <notmyname> kota_: thanks
21:47:37 <notmyname> #topic open discussion
21:47:44 <notmyname> anything else to bring up this week?
21:47:49 <timburke> in those docs, do we...include warnings about how you should only include a single range? or document the existing multi-range behavior?
21:47:59 <onovy> patch 238799
21:48:00 <patchbot> onovy: https://review.openstack.org/#/c/238799/ - Change schedule priority of daemon/server in config
21:48:04 <notmyname> timburke: sounds like a good review comment ;-)
21:48:09 <onovy> we talked about it before chrismas
21:48:31 <kota_> timburke: +1
21:48:52 <notmyname> onovy: that wasn't even this year!
21:48:56 <onovy> notmyname: :)
21:49:03 <onovy> so it's realy really old patch? :)
21:50:41 <notmyname> onovy: I'd love to have some other ops comments on it, too
21:50:56 <notmyname> eg donnagh or ahale
21:51:09 <notmyname> pdardeau: how's the dev_id limit patch?
21:51:26 <pdardeau> coming along, working on getting last unit test to pass
21:51:42 <acoles> notmyname: i'll ask donagh if he'd take a look
21:51:43 <notmyname> pdardeau: cool. I'm looking forward to seeing it
21:51:45 <notmyname> acoles: thanks
21:52:08 <notmyname> acoles: or lorcan
21:52:11 <onovy> 21:34:25 <ahale> hi here o/ yeah thats a good idea imo
21:52:23 <notmyname> onovy: cool
21:52:25 <onovy> 21:34:45 <briancline> onovy: I actually asked our ops folks about this recently. we already control these in production through other means, so we're fine with this going in as long as its optional, which it certainly seems to be
21:52:30 <notmyname> anything else from anyone?
21:52:30 <onovy> notmyname: last swift meeting logs :)
21:52:36 <notmyname> onovy: nice :-)
21:52:48 <timburke> i'd love to get patch 226897 through; currently, swiftclient can't retry failed segment uploads
21:52:48 <patchbot> timburke: https://review.openstack.org/#/c/226897/ - Make LengthWrappers resettable if their _readable ...
21:52:59 <onovy> so conclusion? will look someone to it pls?
21:53:03 <joeljwright> timburke: will take a look
21:53:07 <acoles> timburke: ack
21:53:09 <torgomatic> https://review.openstack.org/#/c/212824/ could use examination
21:53:17 <mattoliverau> onovy: I'll add it to my review list
21:53:18 <timburke> thanks joeljwright, acoles
21:53:22 <notmyname> onovy: can you add those snippets to the review comments? would help (me at least) not ask the same questions over and over about it :-)
21:53:22 <onovy> mattoliverau: thanks
21:53:29 <timburke> i'm also curious to know whether tdasilva and cschwede have gotten a chance to really play with patch 214922
21:53:30 <patchbot> timburke: https://review.openstack.org/#/c/214922/ - Add delete markers to versioned_writes middleware
21:53:35 <onovy> notmyname: yep
21:53:47 <blmartin> I would like to finish out https://review.openstack.org/#/c/257577/ if anyone has time to review. I think its getting close to done
21:53:49 <cschwede> timburke: not yet :(
21:54:31 <notmyname> blmartin: I think I looked at that already. I should look again
21:54:47 <blmartin> that would be great!
21:54:49 <notmyname> torgomatic: yes! that's also something Zyric_ is working on
21:54:55 <notmyname> (the audit watchers)
21:54:56 <Zyric_> torgomatic: Indeed, considering my work so far is heavily based on your patch I think I owe you a review too :)
21:55:13 <Guest36234> I would like to have review on patch 202411 (sorry for my nick)
21:55:14 <patchbot> Guest36234: https://review.openstack.org/#/c/202411/ - Add functional test for access control (RBAC) with...
21:55:26 <notmyname> Guest36234: it's on my todo list
21:55:43 <Guest36234> notmyname: thanks!
21:55:44 <notmyname> we definitely owe you a review on that after the conversation in tokyo
21:55:53 <mattoliverau> +1
21:56:21 <acoles> Guest36234: is that on the <= 10 lines list :) :)
21:56:36 <onovy> blmartin: done
21:56:38 <Guest36234> acoles: lol
21:56:53 * acoles apologises for not reviewing it again yet
21:57:14 <Guest36234> acoles: np!
21:58:08 <notmyname> ok. I think we're done with the meeting for this week. thanks for coming
21:58:18 <notmyname> and thanks for being part of the 509 swift contributors :-)
21:58:23 <notmyname> #endmeeting