07:30:03 #startmeeting Yardstick work meeting 07:30:03 Meeting started Thu Aug 27 07:30:03 2015 UTC. The chair is anac1. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:30:03 Useful Commands: #action #agreed #help #info #idea #link #topic. 07:30:03 The meeting name has been set to 'yardstick_work_meeting' 07:30:11 #info Ana Cunha 07:30:22 #info Sean Wenström 07:30:25 hi, please info your names 07:30:33 QiLiang 07:31:01 #topic Interaction between dispatcher & output manager 07:31:09 #info Patrick 07:31:35 let's discuss diaptacher and output manager to synchronise and agree on the solution 07:31:49 ok 07:31:57 I think we can use OutputMgr as the base class, and FileDispatcher, HTTPDispatcher be the subclass of OutputMgr. 07:32:34 raindirve? 07:32:56 Each subclass implement it's own sotrage part, just rewrite _output_serializer_streamer 07:33:05 interesting, I definitely agree that the dispatcher would make a great backend for the OutputMgr 07:33:17 subclass sounds like a good way to go 07:33:41 #info suggestion to use OutputMgr as base class 07:33:57 use subclass can dismiss confisuion 07:34:33 #info and FileDispatcher, HTTPDispatcher as subclass 07:35:06 raindirve, do i understand you agree? 07:35:21 yes 07:35:28 jnon, any opinion? 07:35:52 qiliang, ok for you, right? 07:35:59 yes 07:36:01 So which dispatcher should be configured in command? 07:36:13 i missed the beginning 07:36:46 for the configuration part i think we can use a config file like rally did 07:38:26 ok 07:38:45 jnon, propose to use OutputManager as base class and dispacher as subclass 07:39:16 ok that sounds good to me 07:39:42 So we need a base config file for common configuration in Yardstick Testing? 07:39:50 #agreed use OutputManager as base class and dispacher as subclass 07:39:51 and i will rename the name, not use dispatcher , just xxOutput 07:39:59 ok 07:40:03 yes 07:40:42 #action QiLiang will rename dispatcher to fit in the agreed solution 07:41:00 anything else on outputmanager & dispatcher? 07:41:25 #info Jingwen 07:41:26 no 07:41:29 let's move on 07:41:37 sorry, i am late. 07:41:43 no problem 07:41:53 #topic Test Case for HA 07:42:11 #info meeting with HA yesterday 07:43:02 #info requirement from HA to Yardstick: test case to "kill" one instance of a service running in the controller node 07:43:13 #info slides available, presented yesterday 07:43:44 #info not decided what service we should start with 07:43:52 #info it could be nova 07:44:18 #info yardstick can use china mobile opnfv lab 07:44:19 I have a question, do we know the behavior of OPNFV 3+2 HA system when we kill the OpenStack service on Control Node? 07:44:52 that is what they (HA) want to understand 07:45:33 for example, if we killed nova in one Control node, does another nova will give the service in another Control Node? 07:45:58 It should probably failover to another or same node 07:46:04 if we kill one, the other have to come up and tke over 07:46:22 HA wants to measure how long time does it take for that to happen 07:46:26 ok. 07:47:15 #info a test case will be drafted together with HA 07:47:29 i think this ha test case is very different for the test cases we implemented 07:47:39 yes 07:47:40 yes its different 07:47:59 #info what questions we have to HA? 07:48:36 if we kill nova instacne this looks like we test if nova api is available 07:48:46 #info do we understand what HA wants to do? 07:49:37 Currently I dont think it fit so well with what yardstick is doing now, but we can have look at it 07:50:03 yes check nova-api and crm status maybe\ 07:50:11 #action all - analyse the requirments from HA until next monday and bring opinion 07:50:50 is that ok that we discuss again next meeting? 07:50:59 yes 07:51:02 ok 07:51:04 ok 07:51:53 great ! 07:51:54 Another thing, we should probably from now on write unit tests for all new features we push. !? 07:52:41 aggree 07:52:51 ok for everyone? 07:52:52 totally agree 07:52:55 yes 07:53:03 aggree 07:53:26 #agreed write unit tests for each new feature added 07:53:51 #topic miscellaneous 07:54:24 #info youtube video with yardstick installation in opnfv channel 07:54:56 #info design meeting with vsperf next monday 07:55:02 Ana, about Yardstick-112, I found that the tools Iperf/Iperf3 can measure the UDP jitter( packet delay variation) between client and server. 07:55:29 As Yardstick has alrealy used Iperf3 to measure the bandwidth, I think we can expend this scenario to support more network metrics measurement. 07:55:37 great idea 07:56:06 #agreed use iperf3 for Yardstick-112 07:56:08 Ana, i'm sorry , i used packet delay variation as end-to-end latency, but they are not the same 07:56:22 and about processing speed, I 'm still investigate in this area. Hoping next week I will finish this investigation and start coding. 07:56:30 Jingwen, ok - thanks for clarification 07:57:15 Patrick, you have the task, let us know when you have a proposal, that sound a good way forward 07:57:30 ok 07:58:29 #info a discussion on a dashboard to report test results has started 07:59:05 #info functest is driving 07:59:26 when ? 07:59:42 the topic will continue discussing tonight in Testing Meeting 08:00:00 i see 08:00:02 discussion on mailing list, continue in test&performance today 08:01:07 ok, that's all for today 08:01:11 #endmeeting