17:00:19 #startmeeting qa 17:00:20 Meeting started Thu Mar 7 17:00:19 2013 UTC. The chair is jaypipes. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:23 The meeting name has been set to 'qa' 17:00:30 Good morning/evening QAers. 17:00:33 morning 17:00:37 hi 17:00:39 hi 17:00:42 hello! 17:00:42 howdy 17:01:07 sorry for missing last week's meeting... 17:01:27 Been pleased to see a bunch of progress in code reviews and new test pushes. 17:01:42 davidkranz: around? 17:01:50 jaypipes: Just back. 17:01:58 sdague: around? 17:02:02 rohitk: evening. 17:02:10 jaypipes: morning :) 17:02:44 OK, so dhellmann mentioned a proposed design summit session that I thought was a great idea... 17:02:54 jaypipes: yes 17:02:55 hello all 17:02:57 #topic Getting Started with Tempest design summit session 17:03:03 donaldngo_hp, sdague: mornin. 17:03:04 oh, right meeting :) 17:03:13 #link https://etherpad.openstack.org/havana-adding-projects-to-tempest 17:03:38 hi 17:03:48 Basic point of the session is to help Ceilometer and Heat folks get familiar with Tempest and help them start to add integration tests for Ceilo and Heat 17:04:02 Which of course I think is a great idea! 17:04:22 jaypipes: Yes, looks good. But first *we* need to decide what a smoke test is :) 17:04:26 But, naturally, there's a bit of a learning curve for new projects learning how Tempest does things, and this session should help in that regard 17:04:38 davidkranz: lol, indeed. could have a whole sesion on that ;) 17:04:48 and Tempest has been shaping up quite awesome in the last six months for more contributions 17:04:53 jaypipes: would be good for new comers to tempest as well 17:05:03 FYI, design summit proposal is here: 17:05:05 #link http://summit.openstack.org/cfp/details/87 17:05:12 donaldngo_hp: yup, totally. 17:05:23 jaypipes: I agree, intro to tempest would be great 17:05:38 do we have an idea on how long our track is going to be? 17:05:43 or the track structures in general 17:05:56 donaldngo_hp: and I think that it would be really useful to devote at least half the session time to the final bullet point on the page... a walk through of adding real test cases for Ceilo and Heat 17:06:11 that way we give those teams a good start 17:06:20 ravikumar_hp: morning :) 17:06:22 sdague: "Intro to Tempest" could be on a non-design-summit track 17:06:29 good morning Jay 17:06:36 davidkranz: it could be, but that's closed 17:06:36 sdague: no constraints, AFAIC 17:06:39 jaypipes: yea maybe get a test checked in, reviewed, and merged into tempest if possible in that session 17:07:02 jaypipes: ok cool 17:07:22 it's been one of those weeks where I've not been able to spend any time doing "real work" 17:07:28 donaldngo_hp: yup, we could even break things into a double session, with the first part a more formal walkthrough of the existing tempest layout and concepts and the following session be actually constructing the first couple test cases for each project. 17:07:52 sdague: heh, understood :) 17:08:03 jaypipes++ 17:08:16 jaypipes: ++ 17:08:16 could we decide next week's QA meeting is a design summit planning one, and give everyone a couple of days to propose remaining ideas for it? 17:08:17 jaypipes: +1 it's a good idea to have a formal walkthrough 17:08:38 then we can figure out what's missing from the track that we really should have 17:08:38 we'll have to wait around for the jenkins run to complete 30-40 minutes 17:08:49 andreaf: yeah, I think so too, so we have at least some material to save and publish uip on openstack.org for interested parties in the future. 17:09:15 sdague: yes, totally. I think that's a great idea. 17:09:34 sdague: Sounds good. 17:09:39 #action jaypipes to send out email to dev and QA list for input on QA track and pointing to next week as the meeting to finalize 17:09:43 Pardon my ignorance..But is Tempest going to be/is the framework for individual projects tests as well ? 17:09:53 jaypipes: do we have a starting point already for such documentation / session? 17:09:59 malini: integration tests, not unit tests. 17:10:13 andreaf: https://etherpad.openstack.org/havana-adding-projects-to-tempest 17:10:16 malini: right, unit tests go back in the project trees directly 17:10:17 jaypipes: I just added a section in there that I feel could be documented 17:10:33 rohitk: excellent, thx :) 17:10:37 jaypipes: I think malini question is relevant. 17:10:53 jaypipes: Most of the tempest tests are actually functional regression tests. 17:11:09 jaypipes: There is more overlap with unit tests than would be ideal. 17:11:28 I discussed this with ayoung in the context of new keystone tests. 17:11:29 davidkranz: yeh, well I think that's design summit topic material as well 17:11:47 sdague: Agreed. 17:11:50 in reality new comers need to realize we haven't figured this all out yet :) 17:11:58 davidkranz: I view them as functional integration tests because Tempest isn't mocking or assuming anything about the environment... it's just testing that the environment you run it against functions appropraiatyely. 17:11:59 so we'll have some guidelines on the good kinds of stuff to day 17:12:11 jaypipes: ++ 17:12:12 to add... that should be 17:12:25 davidkranz: I agree about the overlap of regression testing and unit tests, true. 17:12:36 davidkranz: if you are referring to negative tests currently in tempest 17:12:47 We have a couple needs/process improvements we can do on this 17:12:47 sdague: tht is good to know :) I am an openstack newbie & was having a hard time figuring out the Openstack way of doing QA 17:13:00 jaypipes: Yes, and also that as both unit tests and tempest tests try to become more complete there is potential wasted effort. 17:13:02 malini: embrace the chaos :) 17:13:12 malini: yeh, we evolve it over time to get better on each release 17:13:15 davidkranz: completely agreed. 17:13:26 jaypipes: I will put in a summit topic for this. 17:13:34 davidkranz: I was going to recommend that, thank you. 17:13:35 ok, so lets table the rest of this for next week - for summit discussions 17:13:49 ++ 17:13:56 sdague: you lead, sir. 17:13:58 what about things we need to get on top of right now? like important reviews or bugs 17:14:21 sdague: since I was absent last week, please go ahead and lead the meeting, since I've been away from reviews. 17:14:35 sdague: sorry to put you on the spot :( 17:14:36 can we get this blueprint approved: https://blueprints.launchpad.net/tempest/+spec/update-expected-exception-tests 17:14:56 oooff, as have I most of the week. :) anyway... what about the v3 keystone tests? 17:15:14 sdague: shall we consider donaldngo_hp's BP first? 17:15:16 there were some tests in the queue, but they changed v2 to v3, so dropped v2 testing 17:15:17 sure 17:15:44 I personally have no problems supporting the BP. Glad to see agreement on doing exception assertions. 17:15:44 I'm +1 on that blueprint 17:15:44 sdague: we are following folders - V2 & v3 17:16:07 OK, ghow about this... does anyone OBJECT to the above blueprint? 17:16:11 #link https://blueprints.launchpad.net/tempest/+spec/update-expected-exception-tests 17:16:21 ravikumar_hp: Is this also going to remove the usage of the exception decorators? 17:16:39 donaldngo_hp: ^^ 17:16:46 rohitk: can you give an example? 17:17:06 sdague: rohitk is asking whether the @raises decorator is going away. 17:17:06 yea what would be an example 17:17:18 jaypipes: right 17:17:29 this blueprint basically reduces 4+ lines of code into 1 17:17:55 rohitk: do we have raises decorators in tempest? 17:17:57 I was interested to know if we should follow a standard practice 17:17:58 donaldngo_hp: nah... rohitk is asking about the third way we currently assert exceptions, which is using the @raises unittest2/nose decorator 17:18:01 rohitk: is that used somewhere? 17:18:22 sdague: I haven't checked lately, but just recollecting, do correct me if they're already removed 17:18:33 rohitk: they aren't in there that I can see 17:18:51 Ditto. 17:18:51 sdague: that's great then, thanks for correcting 17:18:53 I think donaldngo_hp's bp is a good cleanup 17:18:58 +1 17:18:59 and the right direction 17:19:15 maybe we can enforce this through tox of having a singlular way of doing exception assertions? 17:19:16 I could see us doing additional things after that, but let's get this cleanup done 17:19:23 OK, sounds like an approve, then? shall I approve it? 17:19:26 for future code submissions 17:19:29 jamespage: +2 17:19:36 jaypipes: +2 17:19:45 done. 17:19:52 donaldngo_hp: go for it, man :) 17:19:53 my guys can take care of this please assign it to me 17:20:08 cant seem to edit it 17:20:13 donaldngo_hp: yeh, lets focus on things that we can do near term. Too often we come up with bigger plans that don't get done, this one is really straight forward, which is nice 17:20:16 donaldngo_hp: done. 17:20:31 cool 17:20:40 #topic Keystone tests v2/v3 17:20:47 sdague: agreed 17:20:50 sdague: you had a q for ravikumar_hp 17:21:16 yeh, ravikumar_hp, you are going to redo the patches with supporting both versions of the api, right? 17:21:43 that was the major complaint on the previous versoin 17:21:54 sdague: yes. Based on the review feedback , going to resubmit 17:22:08 ok, great 17:22:11 that supports both V2 & v3 17:22:45 so I'm good on that, once we see the new reviews 17:23:07 alrighty. 17:23:18 maurosr / mtreinish: you guys have the link to the list of needed tests? 17:23:31 sdague: this one https://etherpad.openstack.org/MissingTempestTests 17:23:33 ? 17:23:37 yep 17:23:41 i don't follow all the tempest reviews, but would appreciate being added to anything relevant :) 17:23:47 that's worth sharing around for people looking for easy stuff 17:23:54 dolphm: awesome, will do 17:24:21 sdague: I think everything currently on it is covered or invalid 17:24:25 except for some xml tests 17:24:35 mtreinish: ok, I guess we need some more generation :) 17:25:00 ++ 17:25:18 ok, honestly, that was much topic list :) sorry for not being more organized this week 17:25:19 sdague: I put a link for a quick howto on the top of that page 17:25:29 i thought there was going to be a write up on how to generate this document? 17:25:42 mtreinish: ty, very useful. 17:25:45 donaldngo_hp: https://etherpad.openstack.org/CoverageAnalysisHowto it's on the top of that missing test list 17:26:11 donaldngo_hp: honestly it's pretty straightforward, just a bit time consuming 17:26:43 We need to do similar for Keystone and Quantum, IMHO... but I believe it would need to be manual, right mtreinish, since those projects do not include the coverage middleware, IIRC 17:27:14 right, that's a good thing to float in maybe a cross project track at summit 17:27:17 jaypipes: yeah, the coverage extension is only on nova 17:27:22 kk 17:27:23 mtreinish: thanks, I'll try to give it a go through and update the etherpad. how often should we do this? 17:27:28 as it would be nice to get something like the coverage extension into the other projects for thiat 17:27:35 right 17:28:16 donaldngo_hp: not very frequently, it shouldnt change that much once we get good coverage 17:28:38 mtreinish: lol, at the rate the upstream projects add new stuff... ;) 17:28:46 heheh 17:28:57 yeh, we only added 20 extensions to nova this cycle :P 17:29:06 right :) 17:29:34 there are a bunch of quantum-related reviews in the queue.. 17:30:04 oh, quantum's a good topic. It would be nice if we could get some engagement from that team to get full tempest functional 17:30:47 sdague: I've seen a few folks talking -- mnewby and a few others -- but it still seems like full tests are a ways away. 17:30:53 yeh 17:31:13 maybe for summit we try to get a tempest session in the quantum track? 17:31:19 drive the conversation over there 17:31:31 sdague: probably a good idea, yes. 17:31:52 sdague: I attend the Quantum meeting every week. I will birng the proposal up next Monday 17:32:03 mlavalle: thanks! 17:32:03 mlavalle: thx! 17:32:51 OK, well besides open reviews, which we all need to get to, are there any other open topics folks wish to discuss? 17:32:56 #topic Open discussion 17:33:22 * jaypipes wonders how the runtime is doing? 17:33:25 jaypipes: can we add tests for incubated projects 17:33:33 like DbaaS 17:33:35 jaypipes: on sec, I can tell you 17:33:42 ravikumar_hp: DBaaS is incubated? 17:33:48 of course separate folders . 17:33:52 ravikumar_hp: yeh, I don't think it's incubated 17:34:10 so I'd say we stay away from that for now 17:34:12 I am not sure . Reddwardf , and Atlas LbaaS 17:34:28 ravikumar_hp: Atlas surely is not... it's essentially being replaced with Quantum LBaaS 17:34:31 until it's in the incubation path formally, I don't think we should be putting things in tempest 17:34:46 there is only so much review time to go around 17:34:50 sdague: Agreed, unless a project member wants to step forward. 17:35:19 ravikumar_hp: I'd say doing it for DBaaS would only be slightly easier since it is, AFAIK, able to be setup via Devstack. 17:35:38 ravikumar_hp: that said, I don't really feel like making the undertaking on that until incubation is formal 17:35:39 davidkranz: even if they do, we have to put some bounds on it, because the core team still needs to take responsibility for code in tempest 17:35:46 like sdague said, only so much time... 17:35:54 okay . we will wait 17:36:08 jaypipes: runtime is about the same 35 - 40 mins on the hp cloud nodes 17:36:14 sdague: kk 17:36:25 sdague: are we not yet doing parallel testr runs? 17:36:29 sdague: what about the rackspace cloud? 17:36:31 we are not 17:36:34 chris yeoh still working on that? 17:36:44 mtreinish: rackspace isn't in the pool right now 17:36:44 mtreinish: it's similar it seems 17:37:00 sdague: no? 17:37:06 interesting... when did that happen? 17:37:10 sdague: ok 17:37:14 jaypipes: so in order to do tempest parallel sanely, we need to get to central resource management 17:37:22 sdague: yup. 17:37:33 so that's mostly going to be design summit discussions to figure out how we finish it 17:37:39 sdague: ok. 17:38:02 sdague: though having tests run entirely in their own tenant should enable parallel execution, no? 17:38:04 between now and then we're trying to refactor so things like the create_server / create_image calls go to some central resource allocation / deallocation points 17:38:23 jaypipes: it could, but it won't be faster 17:38:31 sdague: how so? 17:38:47 because of the amount of work we do in setUpClass 17:39:02 and testr splits at the test level, not the class level 17:39:11 sdague: right, I understand that part 17:39:14 it's a devils in the details thing 17:39:17 ya 17:39:37 so if we do some progressive refactoring of the resource allocators, so we get them all to a couple of central points 17:39:49 We could give an additional chance to nose parallel. 17:39:50 we can then use those to build our own testr "scheduler" 17:40:00 which will give us the optimizing we need 17:40:04 k 17:40:25 which, honestly, is sane regardless, because we'll have central cleanup 17:40:32 afazekas: you are welcome to show a POC for that. I tried three times and ran into bugs in nose each time. 17:40:59 yeh, the reality is moving the resource allocations to common paths will help any solution 17:41:12 and then figured we could hash out the last bits in person at summit 17:41:28 sure 17:41:56 so, sadly, the promiss of having it for grizzly was not true 17:41:57 jaypipes: Ok 17:42:04 but havana-1 seems doable 17:42:17 sdague: underpromise... overdeliver. 17:42:27 sdague: let's say Havana final ;) 17:42:31 heh 17:42:31 sure 17:43:16 OK, any other topics before we break? 17:43:28 jaypipes: Nope. 17:43:31 not from me 17:44:05 OK, folks have a good one. I'll start on the email about next week's meeting and the design summit. 17:44:07 #endmeeting