07:00:05 #startmeeting Yardstick work meeting 07:00:05 Meeting started Mon Oct 12 07:00:05 2015 UTC. The chair is anac1. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:00:05 Useful Commands: #action #agreed #help #info #idea #link #topic. 07:00:05 The meeting name has been set to 'yardstick_work_meeting' 07:00:11 #info Ana Cunha 07:00:18 #info QiLiang 07:00:25 #info Yimin Wang 07:01:04 hi everyone, i have some information first 07:01:19 #topic Test requests 07:01:28 #info gaoliang 07:01:36 #info yardstick received request to run tests for OVS project 07:02:15 #info reuse some of test cases in yardstick backlog 07:03:15 #topic architecture implamentation details 07:03:25 #link https://etherpad.opnfv.org/p/yardstick_framework 07:03:29 #info Jingwen Hou 07:03:48 any further comments on the architecture? 07:04:42 no from me 07:05:20 me too 07:05:59 #agreed team decides on architecture discussed in last meeting october 8th 07:06:34 first to implement, as discussed, context part, comments? 07:07:28 #info start with context implementation 07:08:09 how much do you see needs to be changed in current model? 07:09:42 first we need support bare mantel case, for ha and kvm, i think 07:10:34 i agree, anyone disagree? 07:10:55 agree 07:11:00 agree 07:11:02 #info patrick 07:11:16 #info wuzhihui 07:11:54 yes ,ha kvm need this 07:11:58 #agreed add context for bare metal and ha 07:12:01 at the end of https://etherpad.opnfv.org/p/yardstick_framework i wrote my thought on context implemention 07:12:51 the 6 steps, right? 07:12:53 agree with qiliang. we can create an abstract class: Context, and use subclasses like HeatContest and BMContest for different SUT deployment and info 07:13:08 yes 07:13:54 so we need to adapt the heat deploy we have currently ? 07:14:29 #info proposal for context implementation in etherpad https://etherpad.opnfv.org/p/yardstick_framework 07:15:24 #action anac to add jira tasks for context implementation 07:15:33 i guess heat deploy become a subclass ? 07:15:40 for current heat implementation, just need small change to support different kind of context 07:16:18 ok 07:16:19 kubi: yes 07:16:49 qiliang: from your 6 steps, looks like we can map vsperf too? 07:17:15 do we have more info on vsperf project? 07:18:06 i think use this 6 steps we can support vsperf case. 07:18:25 there is documentation on their repo VSPERF ltd (under docs in VSPERF gerrit) 07:19:05 last week we met, they had some problems to run yardstick 07:19:25 jorgen (jnon) helped 07:19:40 we can create a poc.yaml to store the info about the BM, such us ip/user/key, and the info about the OpenStack info. and each sepcial Context can read and use this info as they wish. 07:19:54 i see, i will read the doc later 07:20:35 qiliang: ok, i have started to read 07:21:04 patrick11: poc.yaml has the info on the hw available also? 07:21:26 yes. 07:22:17 this config file will include the info of SUT which will not be changed frequently. 07:23:09 we need this info, see also https://jira.opnfv.org/browse/PHAROS-30 07:23:10 if yardstick has its own config file, we can reuse it to store these info. 07:23:47 will this be a static file? 07:24:19 i think yes. 07:24:33 ok, how do we keep track of changes (i guess they don't happen so often) 07:26:28 maybe we can fetch the lab info needed to yardstcik its own conf file. so we can change it when we changed another SUT. 07:26:53 #agreed poc.yaml to include SUT info and to be used by context 07:27:29 patrick11: fetch from pahros repo, possibly ? so if they update we get it ? 07:28:24 pharos 07:30:34 so, we'll use the proposal for context implementation, anyone disagree? 07:30:55 agree 07:31:26 #agreed implement context according to the proposal in https://etherpad.opnfv.org/p/yardstick_framework 07:32:35 ok, we know how to continue. anything else on the architecture (we'll keep the etherpad for continuous discussion/updates) 07:33:05 I think first we can create the simple poc.yaml manually. use the info we needed in HA and KVM. Then we can connect with pharos for how to fetch all the info about the lab. 07:33:40 yes, they are not ready, so best to do manually to get going 07:34:19 agree, I think we can modify the file by manual 07:34:41 sry for being late (traffic problems), i agree on the context proposal above 07:34:49 #info poc.yaml will be done in two steps: 1) manually to get progress on yardstick tests , 2) connect to pharos when available 07:35:08 jnon: ok 07:35:37 agree. I saw there is already a yardstick.conf file to store the common info about the yardstick. maybe we can reuse this conf file to store the sut info and openstack info instead to read from the environment variables. 07:36:19 https://gerrit.opnfv.org/gerrit/#/c/2383/1 07:36:25 this patch 07:39:20 good 07:39:20 I think yardstick.conf and poc.yaml maybe should be different files, they have different purpose 07:41:00 ok. 07:42:19 do we agree on separete files or need to discuss further ? 07:42:23 separate 07:42:49 if we use yardstick to test one poc, put yardstick.conf and poc.yaml is reasonable 07:43:13 both are ok for me 07:43:41 one file is simpler for use 07:44:25 i prefer 2 files but 1 is ok for me too 07:44:46 :) 07:45:03 both ok for me 07:45:11 me too 07:45:37 i 'm afraid it will be a little troubule in 1 file ,if we fetch paros 07:45:43 ok start with onw file 07:45:53 :) 07:46:17 2 files are moe reasonalbe. who code who decide? 07:46:23 is pharos a yaml file ? 07:46:29 i agree with kubi 07:46:59 pharos plan for json/yaml 07:47:26 maybe later when paros is read we need generate the config by ourselves 07:48:00 2 files ok? 07:48:07 ok 07:48:14 ok. 07:48:14 ok 07:48:15 ok 07:48:25 ok 07:48:30 #agreed 2 files (yardstick.conf and poc.yaml) 07:48:44 can we move to test result api? 07:48:54 ok 07:49:00 #topic test result api 07:49:30 i commit two patches last week 07:49:41 both for test result api 07:50:08 https://gerrit.opnfv.org/gerrit/#/c/2411/2 07:50:18 https://gerrit.opnfv.org/gerrit/#/c/2383/1 07:50:27 #info two patches https://gerrit.opnfv.org/gerrit/#/c/2411/2 and https://gerrit.opnfv.org/gerrit/#/c/2383/1 07:50:46 we need some changes on the api? 07:51:27 no, i found the solution 07:51:46 :) 07:52:22 any ideas how to version control the api? 07:52:52 we'll need to freeze code eventually... 07:53:58 #action anac, qiliang discuss with functest on version handling for test reult api 07:54:08 #topic test runs 07:55:20 #info wuzhihui is ready with https://jira.opnfv.org/browse/YARDSTICK-147 07:55:39 #info to run current samples 10 times takes about 10 hours 07:56:00 #info this input will be used for proposing a dialy and weekly run for yardstick 07:56:16 all of the samples? 07:56:37 yes. details to be added to jira 07:56:43 do we have log? 07:56:52 yes will add to jira 07:56:53 do we have the duration of each test case 07:56:57 yes 07:57:08 all details to be added in jira 07:57:14 good. 07:57:34 then we can plan the daily+weekly 07:57:45 thanks wuzhihui 07:58:09 great 07:58:18 #action ana add details in jira 07:58:58 anything else? 07:59:02 hi,ana,Yardstick-147 is fininshed 07:59:25 i wrote a email to you 07:59:27 great, thanks ! great job, will add all info in jira 08:00:42 Im currntly doing some CI work, running allt yardstick test inside a docker image 08:00:46 ana, do we need add the time of case running to .json? 08:00:47 can we stat the execution of each test case when it is over and report on the result? 08:00:58 preliminary patch: https://gerrit.opnfv.org/gerrit/#/c/2201/ 08:01:29 jingwen: the time stamp, you mean? 08:01:56 i think jingwen means the duration of each test case 08:02:02 patrick11: that's the idea 08:02:08 I think what jingwen said is the same with me. 08:02:20 ok 08:02:51 jnon i will reveiw the code :) 08:03:16 #info docker ci code https://gerrit.opnfv.org/gerrit/#/c/2201/ 08:03:25 yes take a look pls:) 08:03:52 i will update the patch with some more info later today 08:04:02 ok 08:04:38 that's all for today, keep discussion on architecture i etherpad 08:04:43 thanks all 08:04:46 #endmeeting