22:00:36 #startmeeting qa 22:00:37 Meeting started Thu Sep 4 22:00:36 2014 UTC and is due to finish in 60 minutes. The chair is mtreinish. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:00:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:00:40 The meeting name has been set to 'qa' 22:00:53 hi who is here today? 22:01:03 here 22:01:14 hi 22:01:19 #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Proposed_Agenda_for_September_4th_2014_.282200_UTC.29 22:01:22 hi 22:01:23 ^^^ Today's agenda 22:01:27 hi 22:01:48 hi 22:01:59 * stevebaker lurks 22:02:17 let's get started 22:02:23 #topic Summit Session Topics (mtreinish) 22:02:30 #link https://etherpad.openstack.org/p/kilo-qa-summit-topics 22:02:51 so I started an etherpad to have some initial early discussion around summit topics we want to have 22:03:11 I figured considering the discussion around the new format for design summit it will be better to start this earlier 22:03:20 mtreinish: I just added one 22:03:20 I plan to push it out to the ML after the meeting 22:03:26 but I figured I'd bring it up here first 22:03:42 mtreinish: Can you summarize the end result of that email thread about summit changes? 22:03:54 dkranz: heh, that kind of overlaps with the tempest scope one :) 22:04:13 dkranz: sure, basically it's looking like one day will be all cross-project 22:04:32 2 days will will be the traditional design summit format (with may some more scheduling flexibility) 22:04:55 and the last day will be each program get's an open day 22:05:11 Not sure what that means 22:05:34 For the group to gather and discuss whatever needs to be discussed? 22:05:36 dkranz: kind of like a mini midcycle the each program will get a room and make their own plan and topic 22:05:45 mtreinish: RIght 22:06:02 mtreinish: We used to do that by having mini-qa meetings outside the program 22:06:07 But this will be better 22:06:23 nothing is definite yet, ttx still needs to confirm we'll have space to do this and everything 22:06:30 ok, cool 22:06:49 but assuming this is the plan I think planning earlier is better, because it means we'll have less slots for the traditional design summit 22:07:13 mtreinish: right. THe one I put is actually better in a cross-project slot if there is one 22:07:31 dkranz: yeah that was on my list for the cross project track too 22:07:57 ok does anyone have anything else to bring up on this topic? 22:08:29 looks good 22:08:47 ok, lets move on then 22:08:53 #topic Specs Review 22:09:14 so I don't think we've seen much motion on specs lately 22:09:24 but I know andreaf has 2 he wanted me to bring up here 22:09:40 #link https://review.openstack.org/118352 22:09:47 #link https://review.openstack.org/94741 22:09:58 the first one is something we really need to do soon 22:10:20 right now we can't make forward progress on test-accounts because on a skip exception or failure we leak creds in many classes 22:10:28 mtreinish: I had not seen this. Will look first thing tomorrow. 22:10:39 dkranz: yeah he put it up this week 22:10:57 and the second one is the long standing ssh auth one 22:11:12 which I think warrants a review, because the ssh code has been a continual issue 22:11:35 ok 22:11:48 I'll have a look it later too. 22:12:05 ok cool thanks 22:12:22 does anyone else have an open spec review they'd like to bring up? 22:13:26 no 22:13:34 ok if there aren't any other spec reviews I guess we should move on :) 22:13:43 #topic Blueprints 22:13:53 #link https://blueprints.launchpad.net/tempest/juno 22:14:17 so today was j-3 so I still need to go through and clean up the statuses for the open bps 22:14:25 basically pushing back most of them 22:14:36 but are there any status updates from people on open bps 22:15:13 looking at the high prio ones that are open 22:15:16 about tempest-client-scenarios 22:15:23 #link https://etherpad.openstack.org/p/tempest-client-scenarios 22:15:30 Total: 18 test files (MERGED:9, SUBMITTED:7, NOT YET:2) 22:15:50 masayukig: nice, we're making good progress there 22:15:50 almost there. 22:15:52 mtreinish: I have two patches up for the move-checking-to-client bp that could use reviews. 22:16:07 masayukig: I assume one of those not yet is baremetal? 22:16:16 I think adam_g said he was going to look at that 22:16:24 actually, not. 22:16:32 https://review.openstack.org/#/q/topic:bp/client-checks-success,n,z 22:16:33 oh, cool 22:16:39 heat and stamp_pattern things. 22:17:00 masayukig: ah ok, the stamp pattern has been skipped for a long time 22:17:09 yeah. 22:17:25 I told andreaf the other day we should just have a WIP patch on top of the conversion which unskips it to test if it works 22:17:42 because it's unreliable at gate loads but should work for a one off run 22:17:57 agree 22:18:14 stevebaker: do you want to take a look at doing the client migration for the heat scenario test? 22:18:34 masayukig: the one I'm working on, load balancer, is wip 22:18:51 dkranz: ok, I'll take a look. Those are normally pretty easy to review 22:18:53 mlavalle: yeah, thanks. I know that. 22:19:08 mtreinish: yeah, long but easy. The current ones are not so long actually. 22:19:31 mtreinish: I've just posted a reply to the heat integration tests thread, depending on the outcome of that the heat scenario tests might be deleted 22:19:56 stevebaker: this is just migrating the existing autoscaling test to use the tempest client instead of python-heatclient 22:20:12 oh, nm I misread 22:20:44 the autoscaling test is skipped currently I think 22:21:08 I thought it was skipped on the regular jobs, but runs on the heat-slow jobs 22:21:12 but I haven't looked recently 22:21:49 stevebaker: yeah, that's right. @test.skip_because(bug="1257575") 22:21:56 stevebaker: nope you're right 22:21:59 I had an abandoned review which fixed and unskipped it 22:22:47 anyway we can discuss this more outside the meeting 22:22:52 yep 22:23:04 looking at the other 3 high prio bps 22:23:15 I think api-schema-unification is finished 22:23:23 but I'll check with mkoderer_ before I close it 22:23:42 sdague, jogo: are there any updates on the status of javelin2? 22:24:47 salv-orlando: how about branchless-tempest-extensions ? I saw patches on that before 22:24:55 but I haven't had a chance to look at them yet 22:25:57 ok, well I'll check on those after the meeting... 22:26:06 does anyone else have an open bp to discuss? 22:26:10 otherwise we'll move on 22:26:40 mtreinish: javelin2 is moving along there are some missing logs at the moment but an infra patch should fix that 22:27:09 jogo: ok cool, at what point do you think we can mark the bp as closed? 22:27:22 mtreinish: I haven't seen the BP at all so not sure 22:27:41 mtreinish: well its working and does more then old javelin did 22:27:42 jogo: https://github.com/openstack/qa-specs/blob/master/specs/javelin2.rst 22:27:53 but that's fine we can look into outside of the meeting 22:28:13 mtreinish: poke me tomorrow and I'll check it out 22:28:27 jogo: sure, will do 22:28:34 ok if there aren't any other bps let's move on 22:28:43 #topic Devstack 22:28:56 dtroyer_zz: around? 22:29:23 I probably should have made a bigger deal about having a devstack section in the meeting... 22:29:25 mtreinish: waiting for someone to look at those patches 22:29:29 I'll do that for next week 22:29:30 hey, yes…timezone issues ;) 22:29:40 salv-orlando: ok, that's what I figured :) 22:30:22 dtroyer_zz: well, this is the first time we've had a devstack topic. So I'm not exactly sure what format we should try here 22:30:32 but I guess are there any big devstack topics to bring up? 22:30:45 One thing I'd like to mention is the talk about changing the logging and service names…there is an etherpad to collect notes at https://etherpad.openstack.org/p/devstack-logging 22:31:04 #link https://etherpad.openstack.org/p/devstack-logging 22:31:44 dtroyer_zz: ahh, ok getting rid of the abbreviated names, I think that'll definitely make it easier for people 22:32:15 yeah, although I'm honestly a little misty-eyed to let go of the q-* names ;) 22:32:40 our last active tie to the former name that shall not be mentioned 22:32:58 Anyway, the other is the change for process execution to make the stop_xxx() functions work without screen 22:33:10 #link https://review.openstack.org/117339 22:33:14 heh, I've always liked q more too :) 22:33:44 ooh, yeah to stop using screen in grenade 22:33:48 that should help a lot 22:33:48 this is intended to let grenade stop using screen 22:33:50 jinx 22:34:51 beyond that nothing major happening now 22:35:03 dtroyer_zz: ok cool, thanks for the update 22:35:22 I'll make a bigger deal about having a devstack discussion in the next meeting announcment 22:35:39 that way hopefully we'll get some more people from the devstack team active here 22:35:58 sounds good 22:35:59 ok then does anyone else have anything to discuss on devstack before we move on? 22:36:53 #topic Grenade 22:37:11 jogo, sdague: since you guys have been pushing on grenade 22:37:19 anything noteworthy to bring up here? 22:38:19 timezone issue? 22:38:38 well maybe for sdague it's ~6:40pm here 22:38:46 but we can move on and if they show up later discuss it then 22:38:55 #topic Bugs 22:39:07 so dkranz announced the bug day for next Tuesday 22:39:27 I'll be there :) 22:39:28 we've got a lot of untriaged bugs so it'll be good to clean that up going into the rc period 22:39:59 +1 22:40:12 I think moving forward it'll be good to have someone who is dedicated to watching the bug list 22:40:20 mtreinish: what's usual strategy on bug day? confirming bugs or assign them to someone to fix also 22:40:37 gmann: First, triage 22:40:38 gmann: mostly triage to see if a bug is real or not 22:40:50 and then also to check the status of open bugs that seem stale 22:40:57 but triage is the first priority 22:41:13 We can't really assign bugs to other people 22:41:26 People need to assign bugs to themselves 22:41:33 ya 22:41:37 dkranz: heh, well we could but I don't think it would be too successful 22:41:41 :) 22:41:55 mtreinish: We could give the PTL more powers 22:42:36 heh, I have no qualms about assign bugs to people. I just don't think anyone would care 22:42:50 :) 22:43:04 anyway is there anything else to discuss about bugs? 22:43:13 otherwise let's move on 22:44:03 #topic Critical Reviews 22:44:20 so does anyone have any reviews that they'd like to get some extra eyes on? 22:44:29 https://review.openstack.org/#/c/118078/ 22:44:41 #link https://review.openstack.org/#/c/118078/ 22:44:48 ooh, a devstack review :) 22:45:02 yeah, but not so difficult :) 22:45:11 dtroyer_zz: ^^^ 22:45:48 I have one this week too: 22:45:49 #link https://review.openstack.org/#/c/116786/ 22:46:13 it's the last of the random hashseed bugs 22:46:27 after that is approved we can run tempest with a randomhash seed 22:46:42 #link https://review.openstack.org/#/c/117742/ 22:46:54 I'll add 118078 to the logging list and look at it later 22:47:10 masayukig: oh, yeah that's a good one too fix 22:47:18 dtroyer_zz: thanks:) 22:47:25 I also have: 22:47:27 #link https://review.openstack.org/111635 22:47:38 which will fix an import issue if you don't have a tempest config filew 22:48:47 are there any other reviews? 22:48:50 we have our final grenade patch for ironic testing 22:48:55 #link https://review.openstack.org/#/c/111859/ 22:49:09 thanks to everyone who helped review and merge the huge stack to enable that 22:49:41 ok cool, yeah it'll be good to get that closed out 22:50:18 oh and one more branch from andreaf_: 22:50:32 #link https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:bp/test-accounts,n,z 22:51:06 we changed course a bit on the test-accounts work and made it so by default it'll behave the same as it does today and only work for serial 22:51:20 but it'll allow you to optionally use the yaml syntax for regular user creds 22:51:28 mtreinish: ok 22:51:41 mtreinish: I had one topic for discussion 22:51:43 and when we figure out the resource leaking issue we can move forward with the parallel provider 22:51:49 ok let's move to open discussion then 22:51:54 #topic Open Discussion 22:52:10 I talked to some people today about fault-injection 22:52:21 We have rejected such tests from tempest 22:52:33 But there is a clear desire for them 22:52:45 yeah, because it violates the blackbox nature of tempest 22:52:47 We could create a separate repo for non-functional tests 22:53:02 But is that really worth the trouble? 22:53:20 How terrible would it be to just make a directory in tempest? 22:53:34 The review team would be the same anyway and another repo just seems like a pain in the neck 22:53:39 But we could go that way 22:53:58 dkranz: Honestly I think moving forward with tempest-lib will enable people to do this seperately 22:54:08 I don't think the review team would necessarily be the same 22:54:21 mtreinish: Why not? 22:54:49 well I view doing fault injection as outside the scope of tempest, and honestly we have enough to worry about in tempest right now 22:54:54 Unless some core members are not interested in reviewing such tests 22:55:05 if people want to work on it they can start a separate project for doing it 22:55:21 I know in the past we've discussed fault injection service with an api 22:55:24 mtreinish: you mean separate repo 22:55:28 to kill things like rabbit 22:55:38 dkranz: yeah, it could use things from tempest lib 22:55:50 but it wouldn't be a gating test suite (at least at first) 22:55:57 because it'll be a parallel effort 22:56:11 mtreinish: I would not propose it be gating ever 22:56:24 mtreinish: those kinds of tests need to run for a long time to be effective 22:56:37 dkranz: yeah, that's fair 22:56:56 THough I suppose you could have a "smoke" version that ran for a short time 22:57:19 mtreinish: but it is really for testing horizontal scaling, HA, etc. 22:57:30 mtreinish: but ok, not in tempest 22:57:41 but in QA program 22:57:44 yeah, that's one of the advantages of doing tempest lib 22:58:00 it lets us separate things more clearly on functional boundaries 22:58:23 but reuse the bits in tempest that were causing us to dump everything in there 22:58:30 mtreinish: ok. Such a repo would probably import both tempest and tempest-lib :) 22:58:54 heh, yeah I guess if they wanted to reuse tempest test cases 22:59:02 why not? 22:59:09 it'll be the samething with the stress framework 22:59:14 right 22:59:18 which I think we should spin out at some point too 22:59:41 I agree. Could be in the same repo. 23:00:00 but you could write it so it's not a hard coupling but instead you point it to a unit test dir 23:00:04 anyway we're at time 23:00:10 thanks everyone 23:00:11 mtreinish: ok, byew 23:00:19 #endmeeting