07:00:06 #startmeeting swift 07:00:07 Meeting started Wed Jul 12 07:00:06 2017 UTC and is due to finish in 60 minutes. The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 07:00:10 The meeting name has been set to 'swift' 07:00:16 who's here for the 0700 swift team meeting? 07:00:20 o/ 07:01:01 mahatic: I know there's more than just you here right now ;-) 07:01:05 hello 07:01:17 o/ 07:01:27 notmyname: lol, I'm waiting for other hellos too 07:01:30 o/ 07:01:34 hello 07:01:55 o/ 07:01:55 o/ 07:01:58 I wonder if christian will be here. doesn't seem like he's on irc 07:02:45 welcome, everyone 07:03:08 since I'm chairing both the 0700 and the 2100 meeting today, we've got the same agenda for both :-) 07:03:13 #link https://wiki.openstack.org/wiki/Meetings/Swift 07:03:41 #topic Denver PTG 07:03:48 reminder that the PTG is coming up 07:04:12 if you are able to attend, please make sure you are registered and have hotel room (do it soon. do it today) 07:04:26 we're collecting topics at... 07:04:27 #link https://etherpad.openstack.org/p/swift-ptg-queens 07:05:00 so please add your ideas/curent work/hopes/dreams/fears/thoughts to it 07:05:18 hi cschwede!! 07:05:33 Hi notmyname! 07:05:39 cschwede: we were just starting to talk about the ptg 07:06:39 so seeing as everyone here except me lives *outside* the US and the ptg is inside the US, are there any particular things I can help with? anyone know already they won't be able to go? 07:07:57 I take the silence to mean that I'll see you all in person in denver at the ptg :-) 07:08:08 I won't be able to go 07:08:10 o/ 07:08:21 mahatic: I'm sorry to hear that 07:08:25 no problem, right now from Japan/my company :-) 07:08:37 mahatic: :( 07:08:49 mahatic: :( 07:08:56 if anyone is choosing either the PTG or the summit in sydney, please choose the PTG. this definitely includes swift ops people 07:10:21 please keep looking at the etherpad and add stuff as you have ideas 07:10:31 #topic bug triage follow-up 07:10:46 cschwede: I'm putting you on the spot a little bit here :-) 07:11:11 notmyname: heh, thx :) 07:11:16 at the last 0700 meeting you had some things you said you'd follow up on 07:11:27 cschwede: "i'll have a look at Seans work, and on automating LP in general and will follow up in next weeks meeting 07:11:27 cschwede to start etherpad for bug tag ideas, investigate automation of LP bug state changes and report in next meeting" 07:11:49 yes, so i played a bit with the tools written by Sean Dague (https://github.com/sdague/nova-bug-tools). These are pretty cool already, and we could use them IMO to automate quite a bit 07:12:05 what kind of things will it automate? 07:12:43 #link https://github.com/sdague/nova-bug-tools#existing-tools 07:12:43 for example, closing very old bugs without any changes in the last XXX days (would be my first choice to execute) or cleanup in progress bugs that got a fix 07:13:13 cool, those would both be good 07:13:18 also link missing reviews to bugs (ie where the automation in Gerrit failed because it was not the first patchset) 07:13:49 have you done any dry-run of those yet to see how many bugs they would impact? 07:14:00 all of this needs some consensus, ie what do we want to close for example 07:14:09 yes, it's a large number ;) 07:14:45 sounds nice, it has dry-run 07:15:00 if one uses the default of 6 months, it would be 292 closed bugs 07:15:25 of 434 07:15:33 yes :) 07:15:43 did you check 12 months? 07:15:46 but i think 6 months might be to hard 07:15:53 cschwede: +1 for this "link missing reviews to bugs " 07:16:21 12 months / 365 days would be 173 bugs 07:17:05 I agree with acoles. linking bugs to gerrit would be fantastic 07:17:43 i can paste the "to-be-closed" bugs to an etherpad, so we can do some spot checks before executing the script 07:18:40 since we're not in person, here's my off-the-top-of-my-head thoughts... 07:19:00 re closing old bugs - presumably with some other conditions (like status != confirmed, importance < high)? our two highest importance bugs right now are >12 months old 07:19:22 great! close some old bugs. make the old list tractable. oh, but what if the old bugs are valid. we should check them. but if we check them, why do we need a script... 07:19:41 "Could not submit your paste because your paste contains spam." 07:19:45 thanks etherpad... 07:19:53 have you considered not pasting spam? 07:19:54 ;-)_ 07:20:00 :D 07:20:30 #link http://paste.openstack.org/show/615112/ 07:21:15 i can add some checks for != confirmed and low importance and repost the list of to-be-closed bugs 07:21:17 what's wrong with spam paste? it sounds quite tasty ;) 07:21:50 I'm not sure if right away closing bugs which has importance notmyname: that's a risk, but i'd say it's a minor one. if there is no update within 12 months, not yet confirmed and low prio it should be safe to close. can add a message like "reopen if you think this is wrong" or sth like that 07:23:28 mahatic: oh, I was not suggesting the option is close or not close? 07:23:53 maybe a half-measure would be to set it to needs info? 07:24:23 yeah, i think i can easily modify the script to do that 07:24:32 we should not close bugs marked as wish-list, right? 07:24:39 true 07:25:10 hmm... yeah, spot checking just the titles of them, it's obvious that some are done, some are still important, and some are going to take some time to actually figure out 07:25:39 eg https://bugs.launchpad.net/swift/+bug/1559347 is likely done (based on the title). ie we do concurrent reads now 07:25:40 Launchpad bug 1559347 in OpenStack Object Storage (swift) " Add concurrent reads option to proxy" [Undecided,New] 07:25:42 looks like many really old bugs are in state new 07:26:00 so it might help to add the reviews first 07:26:01 acoles: np! I read the follow on convo a bit later, looks like that's not what we're gonna d 07:26:04 do* 07:26:27 cschwede: yeah, I definitely think linking bugs with gerrit would be the first thing to do 07:27:40 what we could also do is to create an etherpad with bugs in NEW, and a bunch of volunteers grab parts of that list. so everyone tackles 10 or so bugs, and we avoid duplicate work 07:28:21 does anyone else feel like doing the automated process to a huge number of bugs is somehow wrong? or giving up? 07:28:51 I completely understand that there are hundreds of bugs that haven't been looked at in over six months 07:29:15 let's do the following (if you agree): 07:29:32 1. search for existing gerrit reviews and link them (ie bug NEW -> some other state) 07:29:54 2. run tool to close fixed bugs (merged gerrit reviews), but as a dry-run -> save list 07:30:16 3. dry-run close-bug script with low prio and still in new and > 365 days; save that list for review 07:30:18 notmyname: I think it has already been useful if only to present us with a different view of the status quo. But I am nervous about a mass cull. 07:30:39 4. discuss again if it makes sense to close that list from 3. 07:31:31 cschwede: when do we close the list from step 2? 07:32:12 after we reviewed it (should be fine, but at least looking at the titles could help to spot any issues) 07:32:51 what are everyone else's thoughts? acoles, mahatic, m_kazuhiro, kota_, rledisez, mathiasb? 07:33:05 oh, jeffli (sorry) 07:33:40 cschwede: on point 3, low prio means precisely Importance=Low?? so Wishlist is not included? 07:34:10 I think it's good. Agree with acoles that it definitely presents a different (better IMO) view of status quo. And so long as we initially take a look at the list before running the script to close, it seems quite helpful 07:34:11 acoles: we can exclude any bugs with tags (not only wishlist, but also low-hanging-fruit etc) 07:34:49 btw, there are 18 bugs mostly in new that can be easily linked with existing gerrit reviews 07:35:08 I agree with mahatic and acoles 07:35:29 on step 1, the list for bugs we're looking for the gerrit patches is the paste above? 07:35:43 http://paste.openstack.org/show/615112/ i mean 07:35:51 kota_: no, that's the list with bugs without any update in the last 6 months 07:35:59 i see 07:36:20 step 1 seems like an obvious win 07:36:25 so we may need the list for the bugs with *new* status 07:36:47 just asking to LP, maybe :P 07:36:56 step 2. I would hope is a short list (I had always thought that released fixes closed bugs) 07:37:05 kota_: i can do that with the tools 07:37:37 acoles: only if the bug was linked on the first review 07:37:41 https://bugs.launchpad.net/swift/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field 07:37:41 .has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search 07:37:53 oops 07:38:02 the link looks broken 07:38:06 gotta love gerrit urls ;-) 07:38:15 oh, those are launchpad 07:38:27 https://goo.gl/X4f44b 07:38:34 cschwede: yeah, I knew that first review linked to launchpad, but somehow I had hoped that on merge there was another cross-check. But IDK for sure 07:38:37 crazy idea: get openstack community to use tools with reasonable, pastable URLs ;-) 07:38:46 acoles: there isn't :/ 07:38:49 notmyname: yeah, searching the bug reports with NEW status 07:39:06 cschwede: in which case +100 for step 2 :) 07:39:28 cschwede: I think your plan sounds great 07:39:51 there's clearly some details (eg acoles is wise to bring up the specific levels instead of <) 07:40:01 but I think we should start working through it 07:40:06 let me do the following: i dry-run all the scripts, save the output and create an etherpad with task that could be done and the affected bugs 07:40:20 that sounds great. thanks 07:40:21 cschwede: +1, thank you 07:41:03 cschwede: if you have a chance to do that today, I'll include the links in teh 2100 meeting. if not, that's ok, but I'll go over the general plan then, too 07:41:03 Ops, sorry forgot about meeting, was stuck at post office trying pick up the power pack that they said I wasn't home to deliver, when I was in fact at home. 07:41:19 mattoliverau: welcome 07:41:30 notmyname: i'll do that this morning, will send you a mail afterwards 07:41:36 ok 07:41:49 ok, two other topics, I think we can get through 07:41:57 #topic docs migrations 07:42:07 this is mostly an FYI topic 07:42:23 There are many reasons for how we got to this situation but one of them is that I sometimes do not feel confident to *unilaterally* mark a bug as Invalid or Wishlist. I wish there was a voting scheme on launchpad so we could form consensus. 07:42:46 acoles: I can definitely sympathize with that 07:43:12 notmyname: oops, we moved on, docs... 07:43:12 the docs that the docs team has been managing are moving into each respective project 07:43:29 this means that we're taking on a lot more docs in our repo 07:44:03 while this set of work was prompted by bad circumstances (ie layoffs), the end result is very very good 07:44:19 I've been working on the migration, and there will be a few more patches for the import 07:44:25 so here's the high-level view 07:44:41 first, there will be an import. there's been some patches already, and there will be a few more 07:45:14 the import will result in a lot of duplication and awareness of stale docs. we can update and refactor *after* the import 07:45:51 also, in conjunction with the docs import, there is a general restructuring of the docs in each project 07:46:07 you know how we currently have several docs trees, several docs jobs, etc? 07:46:12 all that's going away 07:46:23 we will have one docs directory. one conf.py 07:46:45 \o/ nice, I docs root to rule them all 07:46:59 and all the stuff that's currently in it (ie the "developer docs") will be moved, along with the imports from the docs team 07:47:16 this does mean that a lot of existing pages will move. this means links will break 07:47:25 that's sad 07:47:39 but we're doing it anyway 07:47:49 because the end result is really really good 07:48:14 we (ie us here, the swift team) will have one place where we manage docs 07:48:19 if we want to add something, we can 07:48:22 nice 07:48:25 if we want to delete something, we can 07:48:31 if we want to do whatever, we can 07:48:31 Also having it all in our repo means I can submit a patch to change everything to the queen's English, and acoles can +2 ;p 07:48:47 mattoliverau: soooper 07:48:50 Or would that be a translation :p 07:48:56 lol 07:49:02 lol @translation 07:49:09 it also means that all the docs can be updates with a patch that actually implements stuff! 07:49:39 Yeah that's a big +1 07:49:40 yay 07:49:45 all the existing high-level references (eg api guide, install guide, etc) will link into our singular docs tree 07:49:58 which also means we will have one and only one docs job 07:50:02 *gate job 07:50:21 you build docs. that's it. don't have to ask "which docs?". just docs. done 07:50:49 notmyname: will it be possible to build subsets of docs (for speed, when working on a patch)? 07:50:57 no 07:51:01 only one job 07:51:22 well, maybe you could run sphinx-build locally to do a subset. if you learn how, you can teach us all :-) 07:51:34 nerd swipe alert 07:51:36 but no that's not part of the design of the end goal 07:52:18 any quick questions about the docs stuff? I also want to briefly cover upcoming releases 07:52:56 ok 07:53:01 #topic upcoming releases 07:53:15 I updated the priority reviews page 07:53:16 #link https://wiki.openstack.org/wiki/Swift/PriorityReviews 07:53:32 to have sections for the upcoming releases 07:53:46 ideally, I'd like to tag releases for both swift and swiftclient next week 07:54:07 I expect that swiftclient will happen before swift itself. I want the two patches mentioned there, though 07:54:24 patch 449771 could use some eyes 07:54:25 https://review.openstack.org/#/c/449771/ - python-swiftclient - Buffer reads from disk 07:54:44 the other (stream stdin) is waiting on the author for a foudn bug 07:54:59 when those land, I'll do the release 07:55:28 for swift, it's a little more ... what's the word? "fluid" 07:55:52 ie the list is longer, and some of the listed things haven't even been started 07:56:07 the first 2 patches mentioned are important 07:56:13 patch 448480 needs reviews 07:56:13 https://review.openstack.org/#/c/448480/ - swift - DB replicator cleanup 07:56:53 clay is working on patch 478416 and should have something later this week to review (spoiler: at least a 7x improvement in the ec reconstructor cycle time) 07:56:54 https://review.openstack.org/#/c/478416/ - swift - WIP: Add multiple worker processes strategy to rec... 07:57:10 Nice! 07:57:23 That's the one we discussed in Boston right? 07:57:28 the 3 high priority bugs listed aren't blockers, but they are high priority and should be addressed asap. 07:57:34 mattoliverau: I believe so 07:57:48 Well discussed what we could do and was how to implement Romain's thing 07:57:49 mattoliverau: yes. multiprocess reconstructor. there's more that we discussed, but this is the first step 07:58:05 Cool, I look forward to that! 07:58:40 so instead of going down the list of these to ask for reviews (or possibly patch authors!), there's the list. I trust you all to do what you can :-) 07:58:56 also, the list may be incomplete 07:59:13 if it is, please update the wiki page and let me know. or let me know and I'll update it 07:59:50 (while I don't expect there to be another meeting in here at 0800utc, I do want to respect your time) 08:00:01 Also I was involved in reviewing the earlier db replicator critical bug so will find time to look at the follow-up (or cleanup) tho it seems I'm a co author but I'll look anyway :p 08:00:05 all this sound ok for upcoming releases? any questions? 08:00:13 mattoliverau: thanks 08:00:16 Yup 08:00:46 notmyname: sounds good 08:00:52 sounds good 08:00:52 +1 08:00:54 kota_: rledisez: mahatic: mathiasb: jeffli: m_kazuhiro: cschwede: all good? 08:01:01 +1 08:01:03 +1 08:01:08 great, thanks 08:01:24 thank you for staying up late and leading the meeting! 08:01:33 +1 08:01:36 I'm am really happy you're all working on swift. thank you for your work, and I'm looking forward to seeing you in denver :-) 08:01:46 +1 08:01:49 mahatic: I just missed you all :-) 08:02:00 notmyname: sleep well :) 08:02:02 now! bedtime for me! ;-) 08:02:08 #endmeeting