19:04:06 #startmeeting tripleo 19:04:06 Meeting started Tue Sep 9 19:04:06 2014 UTC and is due to finish in 60 minutes. The chair is tchaypo. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:04:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:04:09 The meeting name has been set to 'tripleo' 19:04:18 #topic agenda 19:04:20 * bugs 19:04:22 * reviews 19:04:24 * Projects needing releases 19:04:26 * CD Cloud status 19:04:28 * CI 19:04:30 * Tuskar 19:04:32 * Specs 19:04:34 * open discussion 19:04:36 Remember that anyone can use the link and info commands, not just the moderator - if you have something worth noting in the meeting minutes feel free to tag it 19:04:38 #topic bugs 19:04:40 #link https://bugs.launchpad.net/tripleo/ 19:04:42 #link https://bugs.launchpad.net/diskimage-builder/ 19:04:44 #link https://bugs.launchpad.net/os-refresh-config 19:04:46 #link https://bugs.launchpad.net/os-apply-config 19:04:48 #link https://bugs.launchpad.net/os-collect-config 19:04:50 #link https://bugs.launchpad.net/os-cloud-config 19:04:52 #link https://bugs.launchpad.net/tuskar 19:04:54 #link https://bugs.launchpad.net/python-tuskarclient 19:05:31 I was going to say "Good morning to the crowd I don't normally see when I'm hosting a meeting", but it seems like all the regulars are here anyway 19:06:03 Criticals for TripleO: 19:06:21 https://bugs.launchpad.net/tripleo/+bug/1316985 is fix-committed- GheRivero_pto, can we downgrade that one now? 19:06:23 Launchpad bug 1316985 in tripleo "set -eu may spuriously break dkms module" [Critical,Fix committed] 19:07:55 hmmm _pto may mean vacation 19:08:56 I will follow up with mkerrin about https://bugs.launchpad.net/tripleo/+bug/1263294 - although I'm not sure why that's assigned to him, so I might have to dig a little deeper 19:08:57 Launchpad bug 1263294 in tripleo "ephemeral0 of /dev/sda1 triggers 'did not find entry for sda1 in /sys/block'" [Critical,In progress] 19:10:06 https://bugs.launchpad.net/tripleo/+bug/1361235 looks like it has a fix in progress 19:10:08 Launchpad bug 1361235 in tripleo "visit horizon failure because of import module failure" [Critical,In progress] 19:10:37 I've updated https://bugs.launchpad.net/tripleo/+bug/1362812 to "fix released" to match heat's status 19:10:39 Launchpad bug 1362812 in tripleo "heat networking auto-discovery causes heat-engine to exit" [Critical,Fix released] 19:11:09 https://bugs.launchpad.net/tripleo/+bug/1365750 is unassigned but seems to be making progress 19:11:10 Launchpad bug 1365750 in tripleo "Ironic jobs failing in tripleo CI due to extra specs error" [Critical,Confirmed] 19:11:21 that one were waiting on some nova patches to land 19:11:40 1365750, that is 19:12:22 and that leaves https://bugs.launchpad.net/tripleo/+bug/1366860 which may have been a glitch and is awaiting confirmation 19:12:24 Launchpad bug 1366860 in tripleo "404 downloading cliff" [Critical,Triaged] 19:13:00 tuskar has https://bugs.launchpad.net/tuskar/+bug/1357525 open 19:13:02 Launchpad bug 1357525 in tuskar "tuskar-api fails with "no such option: config_file"" [Critical,Fix committed] 19:13:06 we could assign that one to derek 19:13:10 will do so 19:13:18 yes, hes not here so he gets all the tickets :) 19:13:24 the tripleo one, not the tuskar one :) 19:13:43 thanks slagle :) 19:14:50 Do we have any other bugs people want to discuss? 19:16:04 the ironic bug in CI 19:16:18 The extra_specs one? 19:16:24 Should be out of CI 19:16:34 I'm not sure the changes from https://review.openstack.org/#/c/119357/ will be merged 19:17:03 so this may take some more time, but we'd probably need lucas or dprince to gather more details 19:17:07 gfidente: it likely wont, but it shouldnt need to be 19:17:20 gfidente: we merged a temprevert and supposedly some fixes going into nova will fix it for us 19:18:22 greghaynes, so this may pause CI for some more time 19:18:35 gfidente: We have a temprevert for that already merged in CI 19:18:44 * tchaypo <3s tempreverts 19:19:12 greghaynes: can you update the bug to mention the temprevert and drop the priority please? 19:19:22 ah okay, didn't get it initially, thanks :) 19:19:26 if it's not blocking CI before, IMO it's still high, but it's not critical 19:19:38 hrmmm 19:20:03 it sounds like you have a different opinion :) 19:20:09 It does still break existing users 19:20:13 which is really annoying 19:20:46 and I think that is one of our criteria for critical 19:20:50 Is this the one preventing me from running devtest locally? 19:20:58 If so, +1 to still critical. 19:21:08 bnemec, I had to USE_IRONIC=0 19:21:10 yes 19:21:20 greghaynes: +1 19:21:21 Yeah, that's bad. 19:21:27 still critical 19:21:47 very good. Keep it critical! 19:22:10 If only we had a common tool devs could use to apply their own temprevert... 19:22:20 more on that later. 19:22:30 No other bugs? 19:24:09 #topic reviews 19:24:23 There's been much discussion on the list 19:24:30 I'm going to toss out a straw man 19:25:00 there seems to be wide agreement that auto-abandon helped us keep the queue in check, and it would generally be a good thing if it came back 19:26:07 Until we can get it implemented, I'm wondering if having cores manually find and close old reviews (with a suitably-worded message explaining that this is not a judgement on the patch, but just an attempt at hiding things that aren't actively being worked on) 19:26:22 would be something people would like to see/be willing to do 19:26:26 counter-proposal 19:26:29 mark them as workflow -1 19:26:34 vs abandon 19:26:50 does that take them out of the current stats? 19:26:58 sure, that works for me too 19:27:00 still tags them but doesn't delete them from the authors on default queue 19:27:06 let's clarify whan an "old review" is 19:27:15 jdob: pretty sure it does 19:27:28 i'd say a review with negative feedback and no response from the owner...for 14 days? 19:27:30 Yes, WIP is excluded from the open reviews list. At least in reviewstats. 19:27:36 slagle: yep 19:27:36 slagle: that was my next thing too, are we going to use a hard deadline or just eyeball the super long ones 19:27:49 I'd actually like to say negative review from a core 19:28:04 ack, sounds fine 19:28:10 yeah 19:28:12 meaning negative review from a core + 14 days? 19:28:35 So if it's negative feedback from a core + no response + 14 days elapsed; any reason not to automate that? 19:28:39 and no subsequent reply explaining 19:28:57 * tchaypo checks code 19:29:02 alexisli: i was reading this as the start to automating it 19:29:05 sort of a dry run 19:29:05 yes, anything that's WIP is filtered form the numbers 19:29:09 I think a safe first step in automation would be a report of such reviews. 19:29:13 jdob: OK works for me 19:29:16 oh look, bnemec confirmed that while I was reading code 19:29:17 before going through the steps of automating it 19:30:34 bnemec: is there any chance you'd be willing to work on that report? 19:31:36 tchaypo: Yeah, I can poke at it. 19:31:36 if not, I think it's probably not too difficult, from what I've seen on the code. 19:31:57 Agreed, shouldn't take too long. 19:32:00 * bnemec knocks on wood 19:32:49 #action bnemec to look at adding a report of items that have a -1 from a core but no response from author for 14 days, as a first step towards possibly auto-WIPing these patches 19:33:16 for the record, this week's stats are: 19:33:18 Stats since the last revision without -1 or -2 : 19:33:21 Average wait time: 11 days, 8 hours, 44 minutes 19:33:23 1st quartile wait time: 4 days, 1 hours, 47 minutes 19:33:25 Median wait time: 7 days, 2 hours, 25 minutes 19:33:27 3rd quartile wait time: 15 days, 19 hours, 38 minutes 19:33:40 I believe the 3rd quartile had hit 18.5 days last time I looked, so that's down a little 19:33:52 tchaypo: actually I think it was no response, not no response from author 19:34:04 #undo 19:34:04 tchaypo: in that someone else can say why the reviewers comment doesn't make sense 19:34:06 Removing item from minutes: 19:34:21 helpful repr is helpful 19:34:26 #action bnemec to look at adding a report of items that have a -1 from a core but no response for 14 days, as a first step towards possibly auto-WIPing these patches 19:34:49 checking the 30-day report, I see 10 cores and 2 non-cores with >60 reviews 19:35:18 you know where would be perfect to add this? reviewstats ;) 19:35:55 mrmm. 19:35:58 Core team size: 23 (avg 1.8 reviews/day) 19:36:40 tweak that number to only allow for 2/7 days not being workdays; add a baseline of 3/day and report on the number of the core team above it.. 19:36:41 personally, I was on vacation for a week. others might have been as well 19:36:57 Yeah, I think a lot of people have had vacation over the last few months 19:37:16 that should largely be stabilizing now 19:37:17 it was pointed out in last week's meeting that it's normal to slump a bit over the northern summer 19:37:24 after which we wont have good excuses :) 19:38:10 I've never noticed these stats at the bottom of the 30-day report before 19:38:12 Changes involved in the last 30 days: 427 (14.2/day) 19:38:15 New changes in the last 30 days: 304 (10.1/day) 19:38:17 Changes merged in the last 30 days: 214 (7.1/day) 19:38:21 Queue growth in the last 30 days: 62 (2.1/day) 19:38:55 That "queue growth" number seems to be a good indication that we're not keeping on top of things 19:39:06 Does anyone have specific hairy reviews they want to call out? 19:39:21 I'm going to mention https://review.openstack.org/#/c/119671/ 19:39:41 all it does at this point is add the ability to manually "tox -ebashate" - we have ~419 errors reported 19:40:01 If it lands, I'd like to work towards getting rid of those 419 reports and then turning this on as a mandatory check 19:40:17 +1 19:40:46 #note Lifeless notes that it would be nice if reviewstats would report on number of cores above the baseline 3 commits/workday 19:40:58 tchaypo: Ultimately I'd like to do that for all of our repos. 19:40:59 tchaypo: I wat? 19:41:15 #undo 19:41:15 Removing item from minutes: 19:41:51 #note Lifeless notes that if we're going to comment on such things, reviewstats would be a good place for a report on number of cores above the baseline 3 commits/workday 19:41:54 I sort of feel like all the focus on stats in our meetings is going to encourage people to game them (i.e. fly by reviews) 19:42:02 tchaypo: I didn't note that either 19:42:07 #undo 19:42:08 Removing item from minutes: 19:42:13 when what we really need is ownershipt to push through the important things... 19:42:16 tchaypo: my only comment about putting things in reviewstats was about the aging report 19:42:32 oh 19:42:41 tchaypo: I have nothing else in my irc log about it 19:42:45 * dprince thinkgs stats are becoming a TripleO waste of time 19:43:02 tchaypo: and we already have reviewer stats that cover how active folk are 19:43:18 tchaypo: I don't think making that be shown differently will change anything 19:44:12 lifeless: sorry, our comments must have crossed in the aether, so i thougt you were responding to me when you must have been typing at the same time as me 19:44:12 stats not important, being active and responsive enough to not push new contributors away does matter 19:44:47 I'd say that stats aren't important, but being able to find the changes that need a push is 19:44:51 jp_at_hp: I agree; the stats are a tool, not the thing itself. 19:45:34 but I agree that any focus on stats should be about how they help us find the important changes, which is why we had a discussion about whether the things we're measuring are useful or not 19:46:22 however, it's :45 so I think we need to take this offline 19:46:39 #topic Projects needing releases 19:46:47 volunteer? 19:47:19 i'll do it 19:47:42 #action jdob to release all the things 19:47:46 #topic CD Cloud status 19:48:12 HP2 is still presenting me with learning opportunities. 19:49:01 Has HP1 been out of action? it's not listed on http://goodsquishy.com/downloads/s_tripleo-jobs.html 19:49:20 I think derekh mentioned redeploying testenvs? 19:49:53 he did that already 19:49:58 he did 19:50:04 dropped the failure rate to 20% onhp1 19:50:04 Which brings up something ive been noticing - I have seen a lot of random test failes where something errors with 'no route to host' 19:50:11 and its happening in all sorts of random places 19:50:13 he mentioned the pass rate was up to 80% 19:50:36 Have others encountered this? 19:50:52 slagle: yeah 80% == 100% - 20% :) 19:50:59 greghaynes: rbrady: mentioned that this morning 19:51:26 lifeless: yea yea, i didnt see your comment :) 19:51:31 slagle: ah :> 19:51:32 hrm, im not really sure what could cause this, but sort of correlates with the TE redeploy 19:51:54 since I think our routing is a constand during a test run 19:52:02 s/constand/constant 19:52:09 it is for comms with the nodes 19:52:17 routes to the internet are well routes to te internet 19:52:42 greghaynes: can you bring this up in channel/on list? 19:52:48 *glances at non-i-watch* 19:52:49 anywho, dont need to debug in the meeting, but might be worth something keeping an eye out for 19:52:53 yea 19:53:11 Do we have a bug open for this? 19:53:14 I'm going to skip the CI topic as already covered 19:53:21 #topic tuskar 19:53:25 bnemec: ah, no. Will do 19:53:32 Do we have anyone from tuskar here? 19:53:34 greghaynes: Cool, thanks 19:53:59 * ccrouch pokes jdob 19:54:00 ya, but i have nothing really to report about tuskar 19:54:17 #topic specs 19:55:59 I'm seeing two landed and one abandoned in the last week 19:56:03 #topic open discussion 19:56:38 #note Reminder that next week's meeting will be one hour later than they have been lately, to be more euro-friendly 19:57:24 \o/ 19:57:45 *grumbles* 19:57:46 tchaypo: will you be running it? I can't get to that timeslot 19:57:54 tchaypo: or do we have a volunteer? 19:57:57 shadower has volunteered 19:58:02 cool 19:58:13 I'll be in german class at that time, so i can't make it either. 19:58:57 I get the sense that moving it an hour later is more euro-friendly and west-apac friendly, but less AU/NZ/CN/JP friendly 19:59:29 tchaypo: lol, thanks for reminding me 19:59:38 so we'll see how that works out - if it goes poorly I'll arm-wrestle shadower to get the time changed back 20:00:06 #endmeeting