21:01:02 #startmeeting swift 21:01:03 Meeting started Wed Jul 26 21:01:02 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:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:07 The meeting name has been set to 'swift' 21:01:08 who's here for the swift team meeting? 21:01:11 o/ 21:01:18 o/ 21:01:21 hello 21:01:21 o/ 21:01:46 hi 21:02:17 hello everyone 21:02:24 tdasilva: ? 21:03:01 joeljwright: ! 21:03:06 hi 21:03:07 good evening 21:03:12 :) 21:03:15 welcome everyone 21:03:36 should be a quick meeting, I think 21:03:43 (I normally think that, though) 21:03:50 Lol 21:03:53 kota_: thanks for chairing the 0700 meeting 21:04:00 +1 21:04:00 is it mattoliverau or mahatic for the next one? 21:04:04 you're welcome 21:04:08 Me 21:04:12 ok 21:04:13 mattoliverau 21:04:36 ok 21:04:46 mattoliverau: please feel free to ping me about the agenda 21:05:01 Don't worry I will :) 21:05:04 quick update on the big docs migration work... 21:05:07 #topic docs migration 21:05:10 status: done 21:05:21 Nice 21:05:36 I just reviewed the stuff with dhellmann. I'll land https://review.openstack.org/#/c/487582/ momentarily, and that's it 21:05:37 patch 487582 - python-swiftclient - moved cli doc to the right place for new links pro... 21:06:01 further docs work will continue in our repos, but the migration of content from the -manuals team is done 21:06:12 i saw that -- what was up with it? i don't really "get" that patch... 21:06:32 still definitely a lot to to do to improve docs overall. I want to talk at the ptg about it :-) 21:06:45 timburke: the redirect goes to /cli/ instead of /cli.html 21:06:51 ie from the main docs pages 21:06:52 ah 21:07:20 timburke: I was thinking the same :) 21:07:36 #topic upcoming releases 21:07:54 @! 21:07:54 <_pewp_> jungleboyj (。・д・)ノ゙ 21:07:56 I must tag swiftclient today 21:08:10 this will be the swiftclient in the pike release 21:08:38 https://review.openstack.org/#/c/475038/ and https://review.openstack.org/#/c/478611/ are what I'm looking at to see if they will be in 21:08:39 patch 475038 - python-swiftclient - Allow for uploads from standard input. 21:08:40 patch 478611 - python-swiftclient - Turn stdin uploads into SLO above 10MB. 21:08:49 ..and I see timur just joined :-) 21:08:55 hi! :) 21:09:38 seems likely these will be landable today 21:10:17 timur: what do you think? 21:10:46 everything will be awesomer in the future 21:11:00 the future may come sooner than you think - but never soon enough! 21:11:06 I just addressed the latest comments from acoles. I think the first patch is ready to merge. The second patch had fewer eyes on it, but Tim looked at it and it seemed ok 21:11:21 does it not blow up with the unicode inputs anymore? 21:11:22 I just +2'd first one 21:11:28 I addressed his comments yesterday. If someone else could look at it, I think we'd be in good shape to merge it as well 21:11:30 acoles: is all about the future 21:11:32 yeah, I think the first one will be pretty easy to be ok with landing 21:11:38 if we can land the 1st one it's be pretty cool 21:11:38 clayg: the unicode thing got fixed a little while back 21:11:48 noice 21:12:18 timur: do we log segments as they upload? 21:12:23 the question for the second is "should we land the second one today and iterate but have it in a release" or should we not land the second one and not have it in a release for 6-8 weeks 21:13:09 timburke: right -- I meant to do that yesterday and forgot -- will do tha tnow 21:13:25 timburke: to answer the question: current patchset does not log segments 21:13:42 but it will be more awesome in the future! like in 30 minutes! 21:13:47 thanks. i think the other two larger concerns i can live with for now 21:14:15 so that's where we are with swiftclient. any thoughts on that? 21:14:35 specifically about timur's second patch landing or not? 21:14:58 the 2nd one seems much more experimental 21:15:19 sorry I did not get time to look at the second one 21:15:23 yet 21:15:37 haven't looked at it for a couple of weeks though (sorry) 21:15:59 * clayg shrugs 21:16:09 the brits are apologizing like canadians ;-) 21:16:22 sorry ;) 21:16:29 timur: I think we can package whatever sha we want for swiftclient same as swift 21:16:50 they both seem like features to me - so I'm not sure either should "block" an upstream release no matter how great they are 21:17:11 what is the *other* driver for a swiftclient release (besides getting these awesome new features into the hands of swiftclient users!?) 21:17:19 a particular product packaging doesn't matter matter as much for swiftclient. most client users will likely get the client from pip, not a distro or product repo 21:17:30 because if we're doing a feature release (which is fine by me) - let's just wait until it has all the features we want to deliver? 21:18:05 clayg: we haven't done one in pike yet, and the deadline for that is tomorrow (ie tag tonight). there's good stuff in it https://review.openstack.org/#/c/485859/2/ChangeLog 21:18:05 patch 485859 - python-swiftclient - 3.4.0 authors/changelog update 21:18:10 if there's good things we're we're keeping from our users because some new feature isn't ready - let's release what's ready and has broad support and call it a day!? 21:18:34 yeah, the only reason today is important for swiftclient is because it's the last day for the pike release cycle for clients 21:18:54 ok, so sounds like merge the new feature with all the +2's and +A's and recent love and reviews - and hold of on the other because - this release is already so awesome you can almost taste it like butter 21:19:08 clayg: +1 21:19:13 so the stream from stdin is a great feature. I'm happy to have just that. but also doing the SLO thing would be even better ;-) 21:19:28 gotta save something for 3.5.0! 21:19:29 :) 21:19:32 lol 21:19:42 ok, swift itself 21:20:05 it's not going to be a big priority for me today with other things going on - but if the stdin needs one more pass for a +A I'm available to merge stuff that's already been beat to death and known to be in good shape ready to merge 21:20:24 I'd like to tag a swift release later this week (and another in about 4 weeks as a final pike release) 21:20:38 timburke: had a +2 on it before I caused trouble 21:20:41 tag *all* the sha's 21:21:01 the biggest thing that hasn't landed yet for the next swift release is https://review.openstack.org/#/c/478416/ 21:21:01 patch 478416 - swift - Add multiple worker processes strategy to reconstr... 21:21:20 which I know several of you have been looking at really hard recently 21:21:24 timburke: acoles: thank you *so* much for putting in so much effort to get that change into shape 21:21:31 I know people are just going to LOVE it 21:21:40 and there's more we can do too!!! whooo hoooo 21:22:29 I'm somewhat sad that https://review.openstack.org/#/c/448480 still doesn't have reviews on it, though 21:22:30 patch 448480 - swift - DB replicator cleanup 21:22:40 if it turns out that acoles and timburke and clayg are the three cores that mostly own that patch... hrmm... maybe I can try to write some more docs or something for folks that need to ramp up on the design more quickly 21:22:53 I think the reconstructor design has a section in the ec_overview acctually 21:23:15 oh right... yeah Pavel's final cleanup there was pretty gravy 21:23:21 notmyname: sorry I didn't make it to that one 448480, had hoped to today 21:23:54 notmyname: maybe tomorrow if multi-proc reconstructor is looking good 21:24:00 it's fine. we aren't as much in a time crunch for swift, and I appreciate your time on the client patch (and the reconstructor patch) 21:24:37 buuuut.... /me looks at tdasilva mattoliverau and kota_ ;-) 21:24:41 IIRC mahatic said at 0700 mtg she would try to look at 448480 21:25:16 notmyname: kota_ has been all over composite builder patch :) 21:25:25 i could have time to look at some patches today 21:25:29 i've been really wanting patch 390781 lately too 21:25:29 https://review.openstack.org/#/c/390781/ - swift - Replace replication_one_per_device by custom count 21:25:48 which one needs eyes rather than? 21:26:05 i'll be off for the next few days, but coming back on Tuesday I could take a look at whatever is left 21:26:14 i meant 448480 or 478416 21:26:37 good question 21:26:45 but I had dayoff on Friday, be back Monday though 21:27:14 ok. given that, I'm only wanting to see the reconstructor patch in this release 21:27:34 we'll have another release very soon (~1 month), and that should include both 448480 and 478416 21:27:40 acoles: nice work on the composite ring builder, great work made me to have time for another review ;) 21:27:58 notmyname: ok, got it. 21:28:03 try it 21:28:12 oh, sorry. patch 478416 *is* the reconstructor patch. that one is most important 21:28:12 https://review.openstack.org/#/c/478416/ - swift - Add multiple worker processes strategy to reconstr... 21:28:31 I was thinking patch 448480 and patch 390781 21:28:31 https://review.openstack.org/#/c/448480/ - swift - DB replicator cleanup 21:28:33 https://review.openstack.org/#/c/390781/ - swift - Replace replication_one_per_device by custom count 21:28:53 oh, patch 390781 is still there!? 21:28:54 https://review.openstack.org/#/c/390781/ - swift - Replace replication_one_per_device by custom count 21:29:44 so for a strict ordering, patch 478416 then patch 448480 then patch 390781 21:29:45 https://review.openstack.org/#/c/478416/ - swift - Add multiple worker processes strategy to reconstr... 21:29:46 https://review.openstack.org/#/c/448480/ - swift - DB replicator cleanup 21:29:48 https://review.openstack.org/#/c/390781/ - swift - Replace replication_one_per_device by custom count 21:30:01 in that order because of the merge conflict on the third one 21:30:10 sound ok to everyone? 21:30:17 make sense 21:30:21 notmyname: yes 21:31:00 I'll try and take a look, but like I said in the 0700 meeting, I'm getting in trouble working too much on my "last" week of holidays ;) 21:31:30 :-) thanks. do what you can 21:31:33 notmyname: I mean... patch 390781 is pretty great, becauase default replication_one_per_device = True is just total garbage/crap 21:31:33 https://review.openstack.org/#/c/390781/ - swift - Replace replication_one_per_device by custom count 21:31:48 but... it's not acctually on the priority review page currently I don't think (I'll add it "somewhere") 21:31:50 but... 21:32:07 I think we also have e.g. patch 472659 21:32:07 mattoliverau: what if we double -- no, triple! -- your normal pay for this week? ;-) 21:32:07 https://review.openstack.org/#/c/472659/ - swift - Allow to rebuild a fragment of an expired object 21:32:23 timburke, lol 21:32:29 which acoles looked at - and is maybe close - but also sort of a big deal 21:33:18 like I think currently you can't use expiring EC objects without boning your consistency engine if you have a disk failure or rebalance (which is like ~= to "you can't use expiring EC objects") 21:33:33 yeah, we need to adjust the priority reviews page somewhat. let's focus on the reconstructor patch for this week, then release and adjust the priority reviews page for what we want to see finally in pike 21:33:40 clayg: on that one ^^ I'd love your opinion on the new header name cos apart from that I am close to +2 21:33:58 oh right, yeah gd, romain - just use x-backend-replication already 21:34:33 is Romain around? maybe I'll just change it 21:34:34 like it should just change to x-backend-ssync or something or whatever - but GAH - get over it - hysterical reasons 21:35:03 ok, https://wiki.openstack.org/wiki/Swift/PriorityReviews updated 21:35:31 #topic ptg 21:35:44 #link https://etherpad.openstack.org/p/swift-ptg-queens 21:35:50 keep working on that, as you have topics 21:36:05 tdasilva: you need to keep advocating for patch 371150 21:36:05 https://review.openstack.org/#/c/371150/ - swift - Return 404 on a GET if tombstone is newer 21:36:21 ... in your infinite free time ... assuming it's ready to go and awesome 21:36:49 #link https://etherpad.openstack.org/p/swift-bug-triage-list 21:37:17 the 2 days of bug triage at the start of the ptg is a great idea. 21:37:24 clayg: we changed the scope to be just for repl, so i think it's ready to go 21:37:27 what do we need to figure out before that? 21:38:20 Who'll be there for the first 2 days and keen.. and that doesn't mean you can triage before then ;) 21:38:28 o/ 21:38:30 *cant 21:38:44 o/ 21:38:52 I'll be around 21:38:54 i'm there the whole time - but I don't see why we have to wait to triage!? 21:39:13 Let's add names to the etherpad so people know who to look for 21:39:15 no need to wait to triage. mattoliverau and tdasilva and timburke have been putting us to shame already ;-) 21:39:26 clayg: exactly 21:39:52 mattoliverau: good idea. I added that to the https://etherpad.openstack.org/p/swift-ptg-queens 21:40:18 I will send an email to the -dev list about this too 21:40:31 cschwede promised I could start doing triage as soon as he posted the list - that looks like the list!? 21:40:40 that's the list! 21:40:41 it's probably a good idea to emphasize that the first effort is just to triage, not fix the bugs...don't know if people have been hesitant thinking they have to pick bugs to fix 21:40:47 but umm.. what is that thing about "won't fix" ??? 21:41:34 I fixed the won't fix line 21:42:06 so what do you want the bug triage days to look like? just getting around a table and starting fromt he top of the list? 21:42:26 do we need anything for that, other that knowing where to meet on site? 21:42:28 Divide and conquer 21:42:32 notmyname: that was my first thought 21:42:35 mattoliverau: +1 21:42:40 notmyname: let's talk about that closer to the PTG - it's not till september right? 21:42:48 let's focus on what we can get done between then and now? 21:43:20 Yeah, if we get triage done we could potentially fix some too :) 21:43:36 i don't want to waste face time doing bug crunching - but if every core can't do 5 a week or whatever it was maybe we have an async bug triage party - or yeah do it in person - probably beers could help pass the time 21:43:47 heh, yeah. over the next 4 weeks (between now and september), I've got 2 weeks of vacation and a week of on-call for jury duty. I'm already feeling like the PTG is next week ;-) 21:44:27 notmyname: wow, yeah your outta time 21:44:38 notmyname: ok, well - it *is* close - but I also think cschwede has set us up nice and pretty - we have a list - we have a rough process - let's just do and have a weekly feedback (in this meeting) 21:44:59 +1 21:45:00 acoles: timburke: tdasilva: any protips for newbs like me that are hoping to grab ~5/wk? 21:45:01 ok, then instead of rushing to schedule something more than a month out, consider this your FYI on the bug triage :-) 21:45:05 mattoliverau: cc 21:45:24 clayg: crank through it while you wait on probe tests? 21:45:24 clayg: under-promise, over-deliver :) 21:45:31 it'll be great to use the face-to-face to discuss the process 21:45:45 timburke: acoles: great advice! 21:46:12 there was some proposed additional tags on the eatherpad - do they make sense to use them? 21:46:26 like to tag bugs toward a specific area of the code base? 21:46:34 clayg: so far my tiny contribution was serendipitous, I have failed to make any dent. 21:46:36 do the bugs you find even work like that? 21:46:40 clayg: i've been using them fwiw 21:47:21 clayg: I think the tags listed are now official on lauchpad meaning they will autocomplete in the textbox 21:47:36 it looks like mostly mattoliverau and tdasilva - so I guess maybe next week we'll see some different names too and that will be great! 21:47:36 which help keep tagging somewhat consistent 21:47:43 clayg: i think especially the needs consensus could be helpful now, ther tags that mark a specific area of the code i'm hoping can be useful in the future ??? 21:47:44 acoles: WFM! 21:48:19 tdasilva: I don't *think* I see any _in bold_ 21:48:38 acoles: tdasilva: consistent tags are great! 21:48:41 does that mean we don't have any "need consensus" atm - or just that they're all tagged in lp instead of bold'd on the eatherpad? 21:49:19 clayg: the one 'needs consensus' i had, got resolved ;) 21:50:04 tdasilva: that's great. I was slightly worried about that tag 21:50:17 that it would just be a way to defer actualy making a decision 21:50:27 so the fact it got resolved is great! 21:50:39 notmyname: i was hoping that the round table at the ptg would be a great way to resolve them 21:50:47 #topic yeah 21:50:52 lol 21:50:54 high-bandwidth conversation and get things done 21:51:00 #topic open discussion 21:51:01 are there other topics to bring up for this week? anything that someone needs help on? 21:52:25 all right, then 21:52:49 I'll be traveling with limited online access for the next two weeks. not sure yet what that means, if anything, for next week's 2100 meeting 21:52:49 That'll be a no then 21:53:28 I guess we take it as it comes then 21:53:40 thank you, everyone, for your work on swift and in the community 21:53:48 and congrats mattoliverau on your new job :-) 21:53:54 we're all very excited for you 21:54:02 Ta :) 21:54:05 mattoliverau: woohoo! congrats! 21:54:06 yay! 21:54:22 #endmeeting