07:00:06 <notmyname> #startmeeting swift
07:00:07 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
07:00:10 <openstack> The meeting name has been set to 'swift'
07:00:16 <notmyname> who's here for the 0700 swift team meeting?
07:00:20 <mahatic> o/
07:01:01 <notmyname> mahatic: I know there's more than just you here right now ;-)
07:01:05 <kota_> hello
07:01:17 <mathiasb> o/
07:01:27 <mahatic> notmyname: lol, I'm waiting for other hellos too
07:01:30 <rledisez> o/
07:01:34 <acoles> hello
07:01:55 <m_kazuhiro> o/
07:01:55 <jeffli> o/
07:01:58 <notmyname> I wonder if christian will be here. doesn't seem like he's on irc
07:02:45 <notmyname> welcome, everyone
07:03:08 <notmyname> since I'm chairing both the 0700 and the 2100 meeting today, we've got the same agenda for both :-)
07:03:13 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
07:03:41 <notmyname> #topic Denver PTG
07:03:48 <notmyname> reminder that the PTG is coming up
07:04:12 <notmyname> 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 <notmyname> we're collecting topics at...
07:04:27 <notmyname> #link https://etherpad.openstack.org/p/swift-ptg-queens
07:05:00 <notmyname> so please add your ideas/curent work/hopes/dreams/fears/thoughts to it
07:05:18 <notmyname> hi cschwede!!
07:05:33 <cschwede> Hi notmyname!
07:05:39 <notmyname> cschwede: we were just starting to talk about the ptg
07:06:39 <notmyname> 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 <notmyname> I take the silence to mean that I'll see you all in person in denver at the ptg :-)
07:08:08 <mahatic> I won't be able to go
07:08:10 <psachin> o/
07:08:21 <notmyname> mahatic: I'm sorry to hear that
07:08:25 <kota_> no problem, right now from Japan/my company :-)
07:08:37 <acoles> mahatic: :(
07:08:49 <kota_> mahatic: :(
07:08:56 <notmyname> 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 <notmyname> please keep looking at the etherpad and add stuff as you have ideas
07:10:31 <notmyname> #topic bug triage follow-up
07:10:46 <notmyname> cschwede: I'm putting you on the spot a little bit here :-)
07:11:11 <cschwede> notmyname: heh, thx :)
07:11:16 <notmyname> at the last 0700 meeting you had some things you said you'd follow up on
07:11:27 <notmyname> 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 <notmyname> cschwede to start etherpad for bug tag ideas, investigate automation of LP bug state changes and report in next meeting"
07:11:49 <cschwede> 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 <notmyname> what kind of things will it automate?
07:12:43 <notmyname> #link https://github.com/sdague/nova-bug-tools#existing-tools
07:12:43 <cschwede> 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 <notmyname> cool, those would both be good
07:13:18 <cschwede> also link missing reviews to bugs (ie where the automation in Gerrit failed because it was not the first patchset)
07:13:49 <notmyname> have you done any dry-run of those yet to see how many bugs they would impact?
07:14:00 <cschwede> all of this needs some consensus, ie what do we want to close for example
07:14:09 <cschwede> yes, it's a large number ;)
07:14:45 <kota_> sounds nice, it has dry-run
07:15:00 <cschwede> if one uses the default of 6 months, it would be 292 closed bugs
07:15:25 <notmyname> of 434
07:15:33 <cschwede> yes :)
07:15:43 <notmyname> did you check 12 months?
07:15:46 <cschwede> but i think 6 months might be to hard
07:15:53 <acoles> cschwede: +1 for this "link missing reviews to bugs "
07:16:21 <cschwede> 12 months / 365 days would be 173 bugs
07:17:05 <notmyname> I agree with acoles. linking bugs to gerrit would be fantastic
07:17:43 <cschwede> 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 <notmyname> since we're not in person, here's my off-the-top-of-my-head thoughts...
07:19:00 <acoles> 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 <notmyname> 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 <cschwede> "Could not submit your paste because your paste contains spam."
07:19:45 <cschwede> thanks etherpad...
07:19:53 <notmyname> have you considered not pasting spam?
07:19:54 <notmyname> ;-)_
07:20:00 <mahatic> :D
07:20:30 <cschwede> #link http://paste.openstack.org/show/615112/
07:21:15 <cschwede> i can add some checks for != confirmed and low importance and repost the list of to-be-closed bugs
07:21:17 <acoles> what's wrong with spam paste? it sounds quite tasty ;)
07:21:50 <mahatic> I'm not sure if right away closing bugs which has importance<high is a good thing to do. We still want "medium" priority bugs to get some attention I suppose
07:22:10 <cschwede> 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 <acoles> mahatic: oh, I was not suggesting <high as an appropriate condition, I was just suggesting conditions. sorry if i confused.
07:23:38 <notmyname> the option is close or not close?
07:23:53 <notmyname> maybe a half-measure would be to set it to needs info?
07:24:23 <cschwede> yeah, i think i can easily modify the script to do that
07:24:32 <acoles> we should not close bugs marked as wish-list, right?
07:24:39 <cschwede> true
07:25:10 <notmyname> 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 <notmyname> eg https://bugs.launchpad.net/swift/+bug/1559347 is likely done (based on the title). ie we do concurrent reads now
07:25:40 <openstack> Launchpad bug 1559347 in OpenStack Object Storage (swift) " Add concurrent reads option to proxy" [Undecided,New]
07:25:42 <cschwede> looks like many really old bugs are in state new
07:26:00 <cschwede> so it might help to add the reviews first
07:26:01 <mahatic> acoles: np! I read the follow on convo a bit later, looks like that's not what we're gonna d
07:26:04 <mahatic> do*
07:26:27 <notmyname> cschwede: yeah, I definitely think linking bugs with gerrit would be the first thing to do
07:27:40 <cschwede> 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 <notmyname> does anyone else feel like doing the automated process to a huge number of bugs is somehow wrong? or giving up?
07:28:51 <notmyname> I completely understand that there are hundreds of bugs that haven't been looked at in over six months
07:29:15 <cschwede> let's do the following (if you agree):
07:29:32 <cschwede> 1. search for existing gerrit reviews and link them (ie bug NEW -> some other state)
07:29:54 <cschwede> 2. run tool to close fixed bugs (merged gerrit reviews), but as a dry-run -> save list
07:30:16 <cschwede> 3. dry-run close-bug script with low prio and still in new and > 365 days; save that list for review
07:30:18 <acoles> 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 <cschwede> 4. discuss again if it makes sense to close that list from 3.
07:31:31 <notmyname> cschwede: when do we close the list from step 2?
07:32:12 <cschwede> after we reviewed it (should be fine, but at least looking at the titles could help to spot any issues)
07:32:51 <notmyname> what are everyone else's thoughts? acoles, mahatic, m_kazuhiro, kota_, rledisez, mathiasb?
07:33:05 <notmyname> oh, jeffli (sorry)
07:33:40 <acoles> cschwede: on point 3, low prio means precisely Importance=Low?? so Wishlist is not included?
07:34:10 <mahatic> 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 <cschwede> acoles: we can exclude any bugs with tags (not only wishlist, but also low-hanging-fruit etc)
07:34:49 <cschwede> btw, there are 18 bugs mostly in new that can be easily linked with existing gerrit reviews
07:35:08 <mathiasb> I agree with mahatic and acoles
07:35:29 <kota_> on step 1, the list for bugs we're looking for the gerrit patches is the paste above?
07:35:43 <kota_> http://paste.openstack.org/show/615112/ i mean
07:35:51 <cschwede> kota_: no, that's the list with bugs without any update in the last 6 months
07:35:59 <kota_> i see
07:36:20 <acoles> step 1 seems like an obvious win
07:36:25 <kota_> so we may need the list for the bugs with *new* status
07:36:47 <kota_> just asking to LP, maybe :P
07:36:56 <acoles> step 2. I would hope is a short list (I had always thought that released fixes closed bugs)
07:37:05 <cschwede> kota_: i can do that with the tools
07:37:37 <cschwede> acoles: only if the bug was linked on the first review
07:37:41 <kota_> 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 <kota_> .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 <kota_> oops
07:38:02 <kota_> the link looks broken
07:38:06 <notmyname> gotta love gerrit urls ;-)
07:38:15 <notmyname> oh, those are launchpad
07:38:27 <kota_> https://goo.gl/X4f44b
07:38:34 <acoles> 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 <notmyname> crazy idea: get openstack community to use tools with reasonable, pastable URLs ;-)
07:38:46 <cschwede> acoles: there isn't :/
07:38:49 <kota_> notmyname: yeah, searching the bug reports with NEW status
07:39:06 <acoles> cschwede: in which case +100 for step 2 :)
07:39:28 <notmyname> cschwede: I think your plan sounds great
07:39:51 <notmyname> there's clearly some details (eg acoles is wise to bring up the specific levels instead of <)
07:40:01 <notmyname> but I think we should start working through it
07:40:06 <cschwede> 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 <notmyname> that sounds great. thanks
07:40:21 <mahatic> cschwede: +1, thank you
07:41:03 <notmyname> 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 <mattoliverau> 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 <notmyname> mattoliverau: welcome
07:41:30 <cschwede> notmyname: i'll do that this morning, will send you a mail afterwards
07:41:36 <notmyname> ok
07:41:49 <notmyname> ok, two other topics, I think we can get through
07:41:57 <notmyname> #topic docs migrations
07:42:07 <notmyname> this is mostly an FYI topic
07:42:23 <acoles> 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 <notmyname> acoles: I can definitely sympathize with that
07:43:12 <acoles> notmyname: oops, we moved on, docs...
07:43:12 <notmyname> the docs that the docs team has been managing are moving into each respective project
07:43:29 <notmyname> this means that we're taking on a lot more docs in our repo
07:44:03 <notmyname> while this set of work was prompted by bad circumstances (ie layoffs), the end result is very very good
07:44:19 <notmyname> I've been working on the migration, and there will be a few more patches for the import
07:44:25 <notmyname> so here's the high-level view
07:44:41 <notmyname> first, there will be an import. there's been some patches already, and there will be a few more
07:45:14 <notmyname> 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 <notmyname> also, in conjunction with the docs import, there is a general restructuring of the docs in each project
07:46:07 <notmyname> you know how we currently have several docs trees, several docs jobs, etc?
07:46:12 <notmyname> all that's going away
07:46:23 <notmyname> we will have one docs directory. one conf.py
07:46:45 <mattoliverau> \o/ nice, I docs root to rule them all
07:46:59 <notmyname> 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 <notmyname> this does mean that a lot of existing pages will move. this means links will break
07:47:25 <notmyname> that's sad
07:47:39 <notmyname> but we're doing it anyway
07:47:49 <notmyname> because the end result is really really good
07:48:14 <notmyname> we (ie us here, the swift team) will have one place where we manage docs
07:48:19 <notmyname> if we want to add something, we can
07:48:22 <mahatic> nice
07:48:25 <notmyname> if we want to delete something, we can
07:48:31 <notmyname> if we want to do whatever, we can
07:48:31 <mattoliverau> 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 <acoles> mattoliverau: soooper
07:48:50 <mattoliverau> Or would that be a translation :p
07:48:56 <acoles> lol
07:49:02 <mahatic> lol @translation
07:49:09 <notmyname> it also means that all the docs can be updates with a patch that actually implements stuff!
07:49:39 <mattoliverau> Yeah that's a big +1
07:49:40 <mahatic> yay
07:49:45 <notmyname> all the existing high-level references (eg api guide, install guide, etc) will link into our singular docs tree
07:49:58 <notmyname> which also means we will have one and only one docs job
07:50:02 <notmyname> *gate job
07:50:21 <notmyname> you build docs. that's it. don't have to ask "which docs?". just docs. done
07:50:49 <acoles> notmyname: will it be possible to build subsets of docs (for speed, when working on a patch)?
07:50:57 <notmyname> no
07:51:01 <notmyname> only one job
07:51:22 <notmyname> well, maybe you could run sphinx-build locally to do a subset. if you learn how, you can teach us all :-)
07:51:34 <acoles> nerd swipe alert
07:51:36 <notmyname> but no that's not part of the design of the end goal
07:52:18 <notmyname> any quick questions about the docs stuff? I also want to briefly cover upcoming releases
07:52:56 <notmyname> ok
07:53:01 <notmyname> #topic upcoming releases
07:53:15 <notmyname> I updated the priority reviews page
07:53:16 <notmyname> #link https://wiki.openstack.org/wiki/Swift/PriorityReviews
07:53:32 <notmyname> to have sections for the upcoming releases
07:53:46 <notmyname> ideally, I'd like to tag releases for both swift and swiftclient next week
07:54:07 <notmyname> I expect that swiftclient will happen before swift itself. I want the two patches mentioned there, though
07:54:24 <notmyname> patch 449771 could use some eyes
07:54:25 <patchbot> https://review.openstack.org/#/c/449771/ - python-swiftclient - Buffer reads from disk
07:54:44 <notmyname> the other (stream stdin) is waiting on the author for a foudn bug
07:54:59 <notmyname> when those land, I'll do the release
07:55:28 <notmyname> for swift, it's a little more ... what's the word? "fluid"
07:55:52 <notmyname> ie the list is longer, and some of the listed things haven't even been started
07:56:07 <notmyname> the first 2 patches mentioned are important
07:56:13 <notmyname> patch 448480 needs reviews
07:56:13 <patchbot> https://review.openstack.org/#/c/448480/ - swift - DB replicator cleanup
07:56:53 <notmyname> 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 <patchbot> https://review.openstack.org/#/c/478416/ - swift - WIP: Add multiple worker processes strategy to rec...
07:57:10 <mattoliverau> Nice!
07:57:23 <mattoliverau> That's the one we discussed in Boston right?
07:57:28 <notmyname> the 3 high priority bugs listed aren't blockers, but they are high priority and should be addressed asap.
07:57:34 <acoles> mattoliverau: I believe so
07:57:48 <mattoliverau> Well discussed what we could do and was how to implement Romain's thing
07:57:49 <notmyname> mattoliverau: yes. multiprocess reconstructor. there's more that we discussed, but this is the first step
07:58:05 <mattoliverau> Cool, I look forward to that!
07:58:40 <notmyname> 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 <notmyname> also, the list may be incomplete
07:59:13 <notmyname> if it is, please update the wiki page and let me know. or let me know and I'll update it
07:59:50 <notmyname> (while I don't expect there to be another meeting in here at 0800utc, I do want to respect your time)
08:00:01 <mattoliverau> 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 <notmyname> all this sound ok for upcoming releases? any questions?
08:00:13 <notmyname> mattoliverau: thanks
08:00:16 <mattoliverau> Yup
08:00:46 <acoles> notmyname: sounds good
08:00:52 <mahatic> sounds good
08:00:52 <kota_> +1
08:00:54 <notmyname> kota_: rledisez: mahatic: mathiasb: jeffli: m_kazuhiro: cschwede: all good?
08:01:01 <m_kazuhiro> +1
08:01:03 <cschwede> +1
08:01:08 <notmyname> great, thanks
08:01:24 <mahatic> thank you for staying up late and leading the meeting!
08:01:33 <mattoliverau> +1
08:01:36 <notmyname> 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 <jeffli> +1
08:01:49 <notmyname> mahatic: I just missed you all :-)
08:02:00 <acoles> notmyname: sleep well :)
08:02:02 <notmyname> now! bedtime for me! ;-)
08:02:08 <notmyname> #endmeeting