22:00:09 #startmeeting qa 22:00:09 Meeting started Thu Jan 9 22:00:09 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:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:00:12 The meeting name has been set to 'qa' 22:00:27 hi 22:00:30 hi who do we have today? 22:00:33 hi 22:00:38 hi 22:00:40 hi 22:00:44 hii 22:00:48 hi 22:00:50 hi 22:01:10 today's agenda: 22:01:12 #link https://wiki.openstack.org/wiki/Meetings/QATeamMeeting 22:01:57 let's get started 22:01:58 o/ 22:02:07 I guess first up we have 22:02:09 #topic Negative test status/discussion (dkranz) 22:02:46 #link https://github.com/mkoderer/tempest/tree/feature/negative_tests 22:02:49 ok, so I got only positive feedback for the negative test gen approach I pushed, and a request for testscenarios usage 22:03:07 Marc made a fork for us to share and pushed the testscenario stuff 22:03:12 dkranz: that's not fair I had a few negative comments :) 22:03:20 dkranz: are you talking about this? https://review.openstack.org/#/c/64733/ 22:03:32 rahmu: yes 22:03:49 I will push tomorrow the newest state 22:03:56 The current state is in https://github.com/mkoderer/tempest/tree/feature/negative_tests 22:04:12 I am going to add validation for the schemas 22:04:40 and I added testscenarios today 22:04:53 so feedback is welcome ;) 22:04:58 We can discuss and then Marc and I would like to know what we think should go in before we remove the WIP 22:05:31 So the current plan is testscenarios (already there) and validation (soon) 22:05:42 Comments? 22:05:52 and unit tests ;) (not pushed yet) 22:06:01 mkoderer: right 22:06:10 mkoderer: that's the right attitude 22:06:27 dkranz: I think that's probably a good starting point for now 22:06:35 I am not talking about what is needed to be "complete" but what is needed to actually submit so others can contgribute 22:06:56 dkranz: yeah that's probably a good base so we everyone can iterate on it 22:07:02 mtreinish: ok, so we will put in validation and some unit tests and then push for real 22:07:09 Are we done with separating the existing negative tests? 22:07:33 rahmu: shouldn't be much left 22:07:47 rahmu: yeah I don't think it's quite a 100% yet 22:08:03 my patch for the Swift tests needs some love :) https://review.openstack.org/#/c/61874/ 22:08:04 but that really isn't the highest priority the separation just helps when we decide to pull the negative tests 22:08:23 rahmu: we've got a section at the end of the meeting for reviews that need attention 22:08:30 mtreinish: Right. We will have to decide how many generated test to run in the gate 22:08:43 okay 22:08:55 rahmu: I will have a look to the patch tomorrow 22:09:31 dkranz: I imagine these tests are fairly quick, the current negative tests are for the most part 22:09:57 mtreinish: Yes, but these will generate a lot more tests 22:10:24 mtreinish: one, for each api, for each resource or json value that can be supplied 22:10:46 mtreinish: I guess we can worry about that later 22:11:04 mtreinish: The biggest part of this job is adding new schemas for each api 22:11:10 yes .. let's care about that later 22:11:12 mtreinish: So it will take a while 22:12:02 * gfidente can't join today, sorry :( 22:12:05 That's it from me 22:12:12 dkranz: ok 22:12:16 then let's move on 22:12:30 #topic Reconsideration of https://blueprints.launchpad.net/tempest/+spec/refactor-rest-client, according to changes (vponomaryov) 22:12:39 vponomaryov: are you around? 22:12:43 yes 22:12:49 ok go ahead 22:12:58 ok I am off.. cu tomorrow 22:13:10 mkoderer: Sleep well! 22:13:15 So, after last BP review it have had changed 22:13:52 Little changes to rest client and two examples of yousing it: https://review.openstack.org/#/c/62923/ and https://review.openstack.org/#/c/64948/ 22:14:24 vponomaryov: so my concern with this blueprint is actually shown in this file: https://review.openstack.org/#/c/64948/6/tempest/services/compute/xml/servers_client.py 22:14:37 things don't actually change that significantly 22:14:47 you drop the one line methods 22:14:54 but the bulk of the file stays the same 22:15:08 and there is a lot of review effort and rebase churn for something like this restructure 22:15:26 we have 25% of code clearing on адфе здфсу 22:15:33 flat place 22:15:50 without inconsistencies 22:16:07 I have mixed feelings about this 22:16:27 The newer projects have all made sure their json and xml are mostly isomorphic an so avoid this issue 22:16:44 We are really talking about the legacy code 22:16:54 And whether it is worth refactoring it 22:17:36 I don't really mean legacy but rather already complete 22:17:40 yeh, with current review load it seems really low priority 22:18:01 dkranz: yeah that's part of my concern here. IMO the effort for doing this really doesn't seem worth it 22:18:15 vponomaryov: What was bugging you that made this your highest priority? 22:18:35 Copy -paste issue 22:19:21 I am working on service clients on new project, and found it as really easy to fix and nice look 22:20:24 vponomaryov: well would just the first part be enough for you then. That way we can avoid the review churn of converting everything? 22:20:35 vponomaryov: So why not just do it there, and only use the first part? 22:21:01 second part was made after sdague comment 22:21:10 about selecting hardent client pair 22:21:17 We can make it nicer for new projects 22:21:21 s/hardent/hardest 22:21:45 Well sdague was assuming I think this would be done for all or none but that may not be right 22:21:54 I agree, at least, with approving changes for rest clietn itself 22:22:47 when, who want make his client pair without copy-paste he just do it 22:22:51 vponomaryov: I think doing it that way will be fine, but if you're refactoring the rest client make sure you add unit tests to cover the changes 22:23:02 that way we can verify functionality moving forward 22:23:12 especially if you're not converting any of the exisiting service clients 22:23:45 mtreinish: unittests should be in the same patch? 22:23:50 vponomaryov: yes 22:23:59 ok 22:24:44 ok I think this topic is done for now 22:24:50 let's move on 22:25:05 #topic Blueprints 22:25:18 are there any other blueprints that people think need attention 22:25:25 or status updates from any open blueprints 22:25:53 I actually have a quick update on bp config-cleanup today 22:26:27 I think what will be the last 2 reorg patches are up for review right now: https://review.openstack.org/#/c/65751/ and https://review.openstack.org/#/c/62063/ 22:26:53 but I wanted to make sure that everyone thinks the reorg is finished or good enough before I think it's read to close 22:26:57 cool, honestly I've been not really doing many reviews this week with the gate backed up the way it is. Trying to not make it worse 22:27:06 and that I didn't miss any configurable options 22:27:26 mtreinish: seems good enough for my tastes, we can pick up other issues after if they come up 22:27:30 sdague: that's fine the second one actually bounced of the gate after about 48 hours because of a merge conflict 22:27:52 sdague: ok then when these last 2 merge I close the bp 22:28:40 so had you intended that bp to also cover the config isolation from the class hierarchy? 22:28:46 or was that outside of it 22:29:00 sdague: not originally, but that ended up being part of it too 22:29:14 because I hit some issues with the decorators that I had to add for the extension stuff 22:29:28 I could make it a separate bp or just tack it on to this one 22:29:36 so we might want to make a task on it then to run through and clean up assigning config pieces to the objects 22:30:40 related to config cleanup, is the CONF of each base.py necessary based on http://openstack.10931.n7.nabble.com/qa-changes-to-interacting-with-Tempest-config-td27732.html ? 22:30:47 sdague: ok will do 22:31:11 ken1ohmichi: so honestly, it should be imported when you need it 22:31:34 ken1ohmichi: that's what we're talking about, getting rid of it from the base test classes 22:31:36 sdague: ok, I see 22:31:39 and switching it to the imports 22:31:39 it's in the basy.py just because we used to build it in the base.py classes and assign it to cls.config 22:31:49 but we should stop doing that entirely 22:31:54 and treat it like logging object 22:32:04 completely outside of the class hierarchy 22:32:10 just import it when yuo need it 22:32:29 it magically lazy loads the first time anyone gets an attr 22:33:17 ok does anyone else have bp updates? otherwise lets move on 22:33:31 sdague, but, for now, it has static proxy class attrs, and in cli tests oslo.config can not be removed 22:33:54 because its grop/options defined in cli module 22:34:23 and never assigned to proxy 22:34:25 vponomaryov: so that's probably true, honestly the cli tests are a bit of a different beast 22:34:33 so I'm not that concerned about them 22:35:13 vponomaryov: I'm not actually convinced of that either but we can save that discussion for later 22:35:27 ok lets move on to the next topic 22:35:41 #topic Bugs 22:36:12 so are there any critical/high bugs that we need to bring up 22:37:03 sdague: you always have something to say about bugs :) 22:37:19 heh 22:37:33 honestly, not this week. I've been too buried trying to get my er data analyzer working 22:37:53 ok, fair enough 22:38:01 then let's jump to the next topic 22:38:11 #topic Neutron testing (mlavalle) 22:38:18 mlavalle: are you around? 22:38:36 mlavalle: the current status is in the agenda, which I updated a couple of hours ago 22:39:07 I just want to highlight that he api gap analysis is complete 22:39:12 in the etherpad 22:39:24 folks are picking up gaps and developing tests 22:39:50 not as much as many as I wanted but it seems to be picking up 22:40:07 mlavalle: where is the etherpad? 22:40:07 and I am making a point of following up daily with them and review their code 22:40:35 https://etherpad.openstack.org/p/icehouse-summit-qa-neutron 22:40:41 in the api section 22:40:47 #link https://etherpad.openstack.org/p/icehouse-summit-qa-neutron 22:41:06 mlavalle: thanks :) 22:41:09 all he negative tests were removed for the ether pad as of last week 22:41:24 mlavalle: I think it might be worth separating the gap analysis and tracking to separate place 22:41:50 it just seems a little crowded on that etherpad :) 22:41:51 mtreinish: you mentioned that a few weeks ago……. 22:42:06 but folks are already going to the etherpad 22:42:14 I don't want to confuse / loose them 22:42:46 that's why I've been hesitant to take the analysis somewhere else 22:42:56 ok, that's fine. 22:43:36 salv-orlando has been making progress with the bugs related to the gate and parallel testing 22:43:53 if he is around I would like him to give some detail 22:44:11 I am around if there is any question 22:44:26 sorry mlavalle did not see your last post 22:44:40 that's all I have 22:45:01 and see you next week in balmy Montreal ;-) 22:45:06 in a nutshell: the most pressing issue, with the connection not being up because of various agent issue will be sorted once the patches under review are merged. 22:45:26 I have filed a list of bugs for "minor" issues. They're all tagged neutron-parallel. 22:45:54 We only have one big problem with a scenario for port quotas, but it's more about how the scenario itself is designed. I'm taking care of that. 22:46:33 furthermore, nati-ueno is looking at a metadata issue that was uncovered once the rest of agent flakiness has been sorted. 22:47:00 this metadata issue causes ssh to not work - even if the vm is reachable (the 'ssh protocol banner' error). 22:47:07 that's all from me. 22:47:11 salv-orlando: ok cool it sounds like things are moving 22:47:30 salv-orlando: oh, so it was related the ssh issue was related to cloud-init 22:48:14 mtreinish: the original ssh issue was related to the agent taking ages to wire ports 22:48:38 and applying iptables over and over, thus delaying further port wiring 22:48:55 once that has been sorted (even if the patches are technically still under review) 22:49:17 I have seen appearing a lot (about 20% of runs) this ssh protocol banner error 22:49:41 nati-ueno has found triaged the bug and assigned it to himself. 22:50:20 ok cool 22:50:37 let's go to the last topic on today's agenda 22:50:46 #topic Critical Reviews 22:51:04 so does anyone have any reviews that need some attention? 22:51:11 rahmu: you had one earlier right? 22:51:34 mtreinish: yes I was mentioning separating negative tests for Swift https://review.openstack.org/#/c/61874/ 22:51:50 #link https://review.openstack.org/#/c/61874/ 22:52:13 There are a lot of reviews sitting with just a -1 from jenkins 22:52:17 rahmu: ok, I'll take a look at it after the meeting 22:52:29 dkranz: yeah that's probably because of the state of the gate now 22:52:46 but I feel the burden on the recheck should be the patch owner 22:52:48 mtreinish: Should people be doing rechecks, or not? 22:53:04 mtreinish: I agree. I'll send a message to the list. 22:53:12 dkranz: I have been, but I guess it just contributes to the load on things 22:53:28 mtreinish: That's why I asked 22:53:41 sdague: do you have an opinion? 22:54:06 so in general I think authors should be responsible for their patches getting past jenkins 22:54:14 but honestly, right now, I wouldn't create more load 22:54:25 which is why I've been trying to just let things clear 22:54:36 unless it's a fix for something which will make the gate better 22:54:46 dkranz: so I wouldn't send an email at this point 22:54:59 sdague: ok 22:55:02 until the gate actually dips below 10 items in it 22:55:27 sdague: Perhaps we should start reviewing things that are in this state 22:55:27 because it hasn't been < 40 since sunday 22:55:43 sdague: Cause otherwise we are jkust shutting down 22:55:49 dkranz: agreed 22:56:28 sdague: I'll send a message about that then :) 22:56:46 sdague: Unless you think I shouldn't 22:56:49 yeh, well that's why I'm organzing Gate Blocking Bug day 22:57:09 sdague: I know but its 2.5 weeks away, right? 22:57:16 yes 22:57:30 but with montreal next week, that was about as good as I was going to get 22:57:42 mtreinish: I also have https://review.openstack.org/#/c/63365/ for fixing a gate failure 22:57:52 #link https://review.openstack.org/#/c/63365/ 22:58:20 ken1ohmichi: ok, I'll take a look in a bit 22:58:29 ken1ohmichi: ok, great 22:58:37 mtreinish: Ithanks in advance 22:58:51 sdague: Speaking of Montreal, should those of us not there try to participate some? What's the best way to do that? 22:58:52 ken1ohmichi: +A, I'll get fungi to put it up to the top of the gate 22:59:07 dkranz: be on IRC? 22:59:20 other than that, I don't think there will be much to do 22:59:22 sdague: I'm always on IRC :) 22:59:24 yeh 22:59:29 sdague: ok 22:59:32 it's not really optimized for people far away 22:59:41 sdague: Sure 22:59:42 sdague: thanks!! 22:59:43 but maybe we'll send people to irc if we get swamped 23:00:12 ok well we're out of time for today 23:00:16 thanks everyone 23:00:18 bye all 23:00:19 #endmeeting