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