07:00:06 <anac1> #startmeeting Yardstick workmeeting
07:00:06 <collabot> Meeting started Thu Sep 17 07:00:06 2015 UTC.  The chair is anac1. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:00:06 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
07:00:06 <collabot> The meeting name has been set to 'yardstick_workmeeting'
07:00:37 <Patrick_> #info Patrick
07:00:44 <anac1> #info Ana Cunha
07:00:51 <kubi> #info gao liang
07:00:56 <Jingwen_> #info Jingwen
07:00:56 <qiliang_> #info QiLiang
07:01:45 <anac1> #topic Discussion with Vaccine
07:01:52 <fuqiao> #info fuqiao
07:02:11 <fuqiao> do we also have GTM meeting or only IRC?
07:02:29 <kubi> https://global.gotomeeting.com/join/187944245
07:02:30 <anac1> GTM also
07:02:36 <Patrick_> both, the gTM meeting is https://global.gotomeeting.com/join/187944245
07:03:16 <anac1> #info xiaoli presents a summary on the vaccine proposal
07:03:20 * rex_lee_ #link https://wiki.opnfv.org/project_proposals/vaccine
07:04:00 <anac1> #info anac asks the team for opinion
07:04:57 <anac1> #info anac asks if the framework proposed should be developed from the start
07:06:29 <anac1> #info anac asks if vaccine team has checked all the existing frameworks in opnfv
07:07:45 <anac1> #info anac asks if they are sure it is not possible to reuse
07:08:20 <kubi> in my opinion,reliability test is complex area ,if our team focus on general  framework, special reliability test can be implement by vaccine, then, yardstick integrated it
07:09:55 <anac1> #info anac suggests to try and reuse the existing frameworks at first approach
07:12:49 <kubi> yes,i agree ,it should avoid duplicate
07:13:08 <qiliang_> +1
07:16:48 <anac1> #info anac asks for the proposal to be updated to reflect to reuse the existing frameworks at first approach
07:17:28 <anac1> #info anac suggests to discuss with ha project for the test cases
07:18:59 <anac1> #info a discussion with ha will happen next week
07:21:13 <anac1> #info a discussion is on-going in the tsc about changing the life cycle of the projects
07:26:00 <fdegir> what is tested is more important than what tool is used for running those tests
07:26:31 <fdegir> has anyone thought about who we are going to integrate all these different frameworks together to OPNFV Platform testing?
07:26:49 <anac1> fdegir: good point
07:26:50 <fdegir> s/who/how/
07:27:04 <fdegir> we have functest, yardstick, qtip, bottlenecks, vaccine
07:28:39 <fdegir> +1 to make the existing frameworks better rather than having multiple half-implemented frameworks
07:29:31 <jose_lausuch> and what do we do with the half-implemented frameworks? :)
07:30:01 <fdegir> jose_lausuch: I think the ones that add more value will stay alive
07:30:18 <jose_lausuch> anyway, I agree with you, unified is better than having separate framworks for each
07:30:22 <fdegir> and to be honest, I still couldn't understand the reason why a new framework is needed?
07:30:27 <fdegir> listening but not clear
07:30:43 <fdegir> why not an existing framework?
07:30:55 <jose_lausuch> yep
07:31:09 <jose_lausuch> maybe different test cases, but using existing framework
07:31:13 <jose_lausuch> besides
07:31:23 <fdegir> having different test cases or test scopes is totally fine
07:31:24 <jose_lausuch> isnt yardstick also open to integrate tools in its framework?
07:31:28 <jose_lausuch> thats also a possibility
07:31:54 <fdegir> anyway, if this goes this way, I see great risk of us (infra projects; releng/octopus) not being able to support all the frameworks
07:32:26 <fdegir> also each new test framework will require specific competence for analysis/troubleshooting
07:32:35 <fdegir> who will do that?
07:32:51 <fdegir> anyway
07:32:54 <jose_lausuch> correct
07:32:58 <fdegir> I agree with qiliang_ and anac1
07:33:08 <jose_lausuch> morgan_orange: hi
07:33:12 <morgan_orange> hi
07:33:17 <fdegir> if anyone really cares what I think
07:33:20 <jose_lausuch> whats your view about having a separate framework?
07:33:23 <jose_lausuch> I care :)
07:33:31 <fdegir> thx jose_lausuch
07:33:52 <fdegir> I want to info
07:34:05 <fdegir> #info Having more/different test frameworks will complicate the integration work
07:34:07 <jose_lausuch> we are discussing that having new test cases (for example for reliability) is completelly fine
07:34:17 <fdegir> #info Increase the load on infra projects (releng, octopus)
07:34:22 <jose_lausuch> but having yet another framework is what we are giving opinions on
07:34:41 <fdegir> #info Will risk us supporting all these frameworks
07:35:13 <fdegir> #info Rather than naming or talking about test activities based on what frameworks are used to run them
07:35:21 <fdegir> #info I prefer to classify what they test
07:35:50 <fdegir> #info And put effort on an already existing framework to make sure the additional test scopes can be covered by them
07:37:20 <fdegir> defining the scope of reliability testing is different than creating a new framework to run  it
07:37:56 <jose_lausuch> yes
07:38:07 <jose_lausuch> and reliability testing is not something simple
07:38:14 <jose_lausuch> there can be a lot of test cases in there
07:38:36 <jose_lausuch> specially in a openstack platform with all the extra features we will have
07:38:37 <fdegir> and it is important to work on the test cases rather than losing focus on developing new test framework
07:38:46 <morgan_orange> +1
07:41:33 <anac1> #info yardstick and ha cooperation will continue
07:42:03 <anac1> #topic output manger and dispatcher
07:42:26 <anac1> #info jorgn asks what is needed from dispatcher from output manager
07:42:51 <anac1> #info can you continue the work output manager?
07:42:58 <qiliang_> ok
07:43:17 <qiliang_> ok
07:43:40 <anac1> #info output manager downprioritized
07:43:58 <anac1> i closed go to meeting
07:44:25 <anac1> #info the work for the dispacher can continue
07:45:24 <qiliang_> i cannot get jorgn's mean
07:45:46 <anac1> do you need anything from output manager for the dispatcher?
07:45:52 <qiliang_> i take the output manager part ?
07:46:17 <anac1> jorgen cannot connect
07:46:48 <qiliang_> in my first implemention output manager is not needed
07:48:25 <Per_H> Testing
07:48:42 <anac1> we wonder if the output manager provides any functionality you need for your part
07:48:56 <Per_H> Jorgen wants to know if the outputmanager is crucial for ongoing tasks for anyone
07:49:10 <anac1> sorry, bad internet connection...
07:49:28 <Patrick_> I think we can mix the output manager and dispatcher together to be implemented. because the dispatcher is the subclass of the output manager.
07:49:47 <qiliang_> not that crucial,
07:51:22 <jnon_> hi i was wondering what functionality you need from the output mgr ?
07:51:41 <jnon_> currently it is not doing much
07:52:19 <qiliang_> during the discussion before, output manager is the base class
07:52:48 <qiliang_> but accully output is not that import, and not doing much
07:53:00 <jnon_> i thought that sean later proposed that we don't subclass but leave the dispatcher as is?
07:53:25 <qiliang_> ok, i agree.
07:53:27 <jnon_> i propose we postpone OutputMgr
07:53:54 <anac1> #info jnon proposes to postpone outputmanager
07:54:32 <qiliang_> :)
07:54:32 <qiliang_> i can get idea for OutputMgr if needed maybe
07:54:53 <jnon_> and I have prepared another patch based on seans previous work on cleaning up the JSON output that is not using OutPut
07:55:23 <qiliang_> ok, got it
07:55:58 <anac1> #agreed postpone outputmanager and to later if/when needed
07:56:04 <jnon_> Ill push my cleanup patch later today
07:56:22 <qiliang_> thanks
07:56:35 <anac1> #topic framework architecture
07:57:19 <anac1> #info continue with the discussion on your view on yardstick ha etherpad about architectural changes
07:57:38 <anac1> #topic qiliang committer promotion
07:57:58 <anac1> #info got 5 "+1" votes, i'll send an e-mail to tsc
07:58:04 <anac1> congratulations!
07:58:13 <kubi> congratulations!
07:58:22 <Jingwen_> congratulations!
07:58:23 <Patrick_> great!
07:58:24 <qiliang_> thanks ana and the team
07:58:47 <anac1> that's all for today, thanks all !
07:58:51 <anac1> #endmeeting