07:30:02 #startmeeting Yardstick work meeting 07:30:02 Meeting started Thu Oct 22 07:30:02 2015 UTC. The chair is anac1. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:30:02 Useful Commands: #action #agreed #help #info #idea #link #topic. 07:30:02 The meeting name has been set to 'yardstick_work_meeting' 07:30:09 #info Ana Cunha 07:31:10 #info gao liang 07:31:24 #info patrick 07:31:32 #info Yimin wang 07:31:33 #info Jingwen Hou 07:31:45 #info Rex 07:32:03 #topic OPNFV community labs 07:32:34 #info pharos projects has asked all PTL's to inform on lab needs 07:32:38 qiliang asked for leave for business issues, so he cannot attend this meeting. 07:33:04 patrick11: ok, thanks for information! 07:33:17 #link https://wiki.opnfv.org/projectreqonpharos 07:33:40 #info link above contains yardstick's reply 07:34:30 #info yardstick intends to use ericsson lab, huawei lab, zte lab, china mobile lab, linux foundation lab 07:35:07 #info and other lab for verifying the test cases for the projects we received requests from 07:35:42 nice. 07:36:21 #topic yardstick-172 (sla check of scenarios) 07:37:26 any further comments ? 07:37:29 we seems lack some lab resources in huawei lab. I will track this issues and try my best to support this resource config. 07:37:49 patrick11: great, thanks ! 07:38:35 comments has changed 07:39:05 comments has modified 07:39:47 not say new comments 07:39:57 not see new comment 07:40:00 sorry 07:40:08 no problem 07:40:51 no newer comments from me 07:40:58 #info no new comments 07:41:40 #topic yardstick-168 (heat context refactor) 07:42:18 Qiliang push a patch to refactor runner_cfg host/target info handle, as specified at https://etherpad.opnfv.org/p/yardstick_framework step 4. Get general Context info (use Context.get). 07:42:32 gerrit link: https://gerrit.opnfv.org/gerrit/#/c/2693 07:42:58 #action all review latest patch https://gerrit.opnfv.org/gerrit/#/c/2693 07:43:22 This patch changes all the existing test scenarios, so Qiliang asked everyone pls help to review the code to double check. 07:43:56 #info the patch affects ALL existing test scenarios 07:44:35 #info follow up on next meeting so make sure the sample authors review the patch 07:44:46 great 07:44:59 thanks 07:45:12 #topic yardstick-108 (coverage report) 07:45:32 #info agreed from last meeting to discuss again today 07:46:05 comments ? when merged, this will affect all code 07:46:17 yes, i need your opinion 07:47:30 4 extra missing lines is same as rally's standard 07:48:09 I think 4-line requirement might be a bit too strict at first, we could start with something more lax and then move to a tighter solution once everybody has got used to the initial changes 07:49:06 yes,our ut coverage rate is not good as rally , if we use this standard, it will be strict 07:49:44 krihun: have a suggestion on how to start? 07:50:08 jnon ? 07:50:32 I really don't know, maybe start with a 10-line requirement at first and see how well it is adopted? 07:50:51 how about that i don 't check the extra missing 07:51:02 i just give the coverage report 07:51:30 i think it is good to check the missing 07:51:54 I agree with Ana, this gives motivation to write unit tests 07:52:02 we could start with 10, like krihun says, and see how it goes 07:52:19 ok, no problem , i think this is a good idea 07:52:28 i agree 07:52:53 anyone disagree to start with 10? 07:52:56 agree 07:53:27 agree with ana. I think in Milestone D we will try best to finish the critical features and codes. but I think in Milestone E we should down to the 4-lime requrement like the rally. we should pay for the technical debt in release B? 07:54:16 patrick11: agree 07:55:04 #agreed start with 10-line restriction, report back every meeting 07:55:15 ok 07:55:19 #info goal is 4-line for milestone-E 07:55:37 ok, ths 07:56:07 #topic yardstick-166 07:56:28 yes ,i add some coment on it 07:56:47 i have got the total time and the time of each task with code, however , "Runner.queue" was released before getting total time, so i can not put "total time" into result file, i 'm not sure it is ok that i use "log.info" to print "total time" to console , All comments are welcome~ 07:57:41 i think it is ok, you get the time for each task, right? 07:57:50 yes 07:58:24 i get two time : one is total time , another is task time 07:59:04 if a test suite is run, total time is sum of each task time 07:59:40 yes, you get each task, not i think this is ok. anyone has other opinion? 08:00:02 I think these are enough for testers basic using. so that's ok for me. 08:00:02 yes, you get each task, SO i think this is ok. anyone has other opinion? 08:00:42 #action anac to comment on jira, ok to use the tasks 08:00:56 no i think this is good enough 08:01:20 jnon: you agree? 08:02:01 #agreed the proposal to use tasks time is ok 08:02:15 #topic test case description template 08:02:35 #info updated yardstick-2 with comments from last meeting 08:03:15 #info small addition to include the scenario options used 08:03:20 i agree 08:03:42 ok, thanks 08:03:51 great, i will check it after meeting 08:03:57 that was all for today, thank you everyone 08:03:59 by the way , there are some discussion on the https://etherpad.opnfv.org/p/yardstick_framework about the context type and the sample of pod.yaml , waiting for further comments:) 08:04:06 anac1, about 166 ,i clarify that task time also can't be put into result file , i' m sorry if i let you misunderstand 08:04:40 #action all read discussion and comment on https://etherpad.opnfv.org/p/yardstick_framework 08:05:18 kubi: ok, i'll add comment in jira 08:05:23 ok 08:05:33 #endmeeting