17:02:52 #startmeeting QA 17:02:52 Meeting started Thu Dec 20 17:02:52 2012 UTC. The chair is sdague. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:02:55 The meeting name has been set to 'qa' 17:02:59 hi 17:03:16 ok, so I know we're missing jay and davidkranz, so it's going to be a pretty open floor today 17:03:25 does anyone have topics for discussion to bring up? 17:03:39 sdague: I am here for the moment but may drop out at any time. 17:03:44 ok 17:04:00 one question: should we remove nova volume tests now 17:04:07 sdague: I think the bigggest issue is the full gate. 17:04:20 ok, lets talk about gate first 17:04:28 #topic Tempest Full Gate 17:04:40 sdague: There is no evidence that the build ERROR problem remains. 17:04:45 so, I think that mtreinish and I got to the bottom of the flakey issue 17:05:04 sdague: That was good work. Thanks. 17:05:11 which turned out to be hitting the memory limits on the ci guests because we didn't delete synchonously 17:05:38 davidkranz: yeh, it was fun to get to the bottom of that one, couldn't have done it without mtreinish 17:05:53 davidkranz: so our remaining issue is time to run, correct? 17:06:07 sdague: Right. Parallel is the only solution. 17:06:32 davidkranz: right, cyeoh is looking into doing a testr conversion like nova just did 17:06:36 sdague: Especially because new tests keep coming online, which is good but increases time. 17:06:38 May I know how is parallel execution solution going on? 17:06:42 we should trace the expensive resources like server and volume, when we try to schedule tests in parallel 17:07:06 We should try to reuse servicers on more cases 17:07:12 afazekas: testr does some of that automatically 17:07:20 afazekas: It is possible we could turn an almost full gate on by dropping most of the server tests until we have paralle. 17:07:47 chunwang: because of the holidays, it probably won't see much progress until Jan 17:07:51 davidkranz: yes. but include one of two servwer tests 17:07:57 will a existing test framework or tools used for Tempest parallel exeution? 17:07:59 We should add some annotation in order to mark the what resource a test case needs, and case should push back resources to the pool 17:08:12 Ravikumar_hp: At the summit we talked about marking some tests as "slow". 17:08:17 Or there is a brand new framework from every begining? 17:08:29 chunwang: the intent is to use testr, which is just a different test runner 17:08:41 I've got to run now and wil be back in 15 min or so if you all are still around. 17:08:41 if you look at nova, it just converted to that last week 17:08:58 sdague: ok, go it 17:09:14 some cleanups will have to be made, based on the nova experience 17:09:25 it will make for overall cleaner tests 17:09:55 sdague:OK. I will check the 'testr' capabilites before I try to reinvent the wheel 17:10:12 sdague: will the new scripts expected to be created in new format for testr from now on? 17:10:19 what happened to the exploration of testtools? 17:10:28 #link https://testrepository.readthedocs.org/en/latest/MANUAL.html 17:11:00 chunwang: the test format doesn't really change 17:11:50 sdague:ok 17:12:12 donaldngo: there could still be alternative approaches, testr has some nice regression bisection and speedups that I think are good 17:12:30 sdague: who is doing POC for testr? 17:12:42 the material looks good and promising 17:12:47 cyeoh, he's on my team in australia 17:12:53 great 17:13:15 ill take a look a testr as well 17:13:41 yeh, lifeless, who is in #openstack-dev is the maintainer as well, so has been helping on conversions 17:13:52 and weird edge conditions 17:14:52 mostly in nova we had that because tests caused side effects, and running in parallel exposed that 17:15:20 sdague: what kind of side effects? 17:15:23 the last full gate comment I had, was it might be good to turn it on for devstack 17:15:43 sdague: is there anything blocking that right now? 17:15:47 as it's not flakey any more, and it will run a little more often then on tempest, as the devstack code stream is moving faster 17:15:58 not except asking dtroyer if he minds 17:16:06 sdague: heh, ok 17:16:24 chunwang: like one test would change a global variable, which would effect how a test ran later 17:16:30 basically state leakage 17:16:47 ok, I think we're probably done on that topic 17:17:07 sdague: then suppose it's will take some time to fix... 17:17:09 #topic Removing Nova Volume Tests 17:17:21 Ravikumar_hp: go 17:18:01 sdague: looks like nova blueprint to remove nova volume and migrate to cinder is almost complete 17:18:11 shoud we remove nova volume tests 17:18:22 Ravikumar_hp: sounds good to me 17:18:24 Ravikumar_hp: do you mean the volume extension tests? 17:18:43 other wise tempest will break. yes volume extension tests 17:19:22 Ravikumar_hp: you willing to do the patch to do that? 17:19:28 we can just handle it in review 17:19:29 Ravikumar_hp: I'm pretty sure that won't cause any issues being in there (despite being slower) 17:19:32 yes . i will 17:19:51 ok, so we can make the decision on the review then, as we're missing a bunch of key folks here 17:19:52 it all gets piped to cinder eventually 17:20:15 #action Ravikumar_hp to propose review to remove nova volume tests 17:20:35 next topic? 17:20:41 mtreinish: Thanks . will check with Nova dev team and do accordingly 17:20:49 sdague: I can talk a bit about the coverage stuff 17:21:00 #topic Tempest Coverage 17:21:01 I want to know the progress of quantum related test scripts. 17:21:18 chunwang: we'll do that next 17:21:18 so the nova coverage extension got merged last week 17:21:30 sdague: sure. 17:21:34 I've got a few cleanup patches in the queue before it's 100% 17:22:12 but after those go through I need to add support to devstack-gate and jenkins to do the runs with coverage enabled 17:22:27 the issue is going to be syncronizing those changes with tempest 17:22:49 because the way I wrote the tempest support breaks devstack gate without an exclude arg to nose 17:23:22 but it's almost ready, it's the final stretch 17:23:30 mtreinish: nice 17:23:53 mtreinish: great work on the coverage extension! 17:24:06 rohitk: thanks 17:24:48 ok, anything else on coverage? 17:25:02 sdague: not from me 17:25:11 #topic Quantum in Tempest 17:25:21 ok, does anyone have an update there? 17:26:05 going once... going twice ? 17:26:12 I saw there are 2 blue print for quantum tests...but seems no update for both of them. 17:26:45 yeh, I don't know, and I don't know who's spear heading those 17:26:47 and not sure whether both of the blue print will be adopted. 17:27:02 ok, so I'm going to suggest we move on 17:27:09 #topic Open Discussion 17:27:20 ok, any other topics people want to bring up? 17:27:26 I have another question is... 17:27:46 whether there is any one creating some scripts to verify every compute node is working 17:28:42 chunwang: can you explain more? 17:28:50 https://blueprints.launchpad.net/tempest/+spec/multinode-testing <-- I saw a blue print for multiple node, but not sure whether it's the same meaning as mine. 17:29:00 for example 17:29:10 chunwang: no, that's having the tempest runs run on multiple servers 17:29:18 instead of just a single machine devstack 17:29:25 so it would be more realistic 17:29:26 there are 20 compute nodes in the deployed env, but some of them are not working 17:29:48 when instances assigned to the unavailable nodes, it will be fail 17:30:12 chunwang: so that I think is really outside the role of tempest. It's testing interface functionality, it's not a health monitor 17:30:30 yes, but I suppose tempest is for integration test 17:30:54 who will care about the real deployment env test? 17:31:25 not tempest? 17:31:41 chunwang: that I think is beyond the scope of this project. I could see that as another project that someone might want to create. 17:31:47 but that's just my opinion 17:32:37 sdague: +1 17:33:10 sdague: yes. I agree. +1 17:33:23 ok, so any other topics for discussion 17:34:20 going once... 17:34:38 going twice ... 17:34:46 ok, I'm going to call it 17:34:49 #endmeeting