18:14:46 <dfarrell07> #startmeeting cperf
18:14:46 <collabot`> Meeting started Thu Jun  2 18:14:46 2016 UTC.  The chair is dfarrell07. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:14:46 <collabot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:14:46 <collabot`> The meeting name has been set to 'cperf'
18:18:24 <dfarrell07> #link http://testresults.opnfv.org/reporting/functest/release/master/index-status-apex.html Functest status page for Apex, red because they don't have enough runs I'm told
18:22:19 <dfarrell07> #info Al has an update on test strategy on CPERF-3 JIRA
18:22:20 <jamoluhrsen> #link https://build.opnfv.org/ci/view/cperf/job/cperf-apex-intel-pod2-daily-master/ cperf job running
18:22:26 <dfarrell07> #link https://jira.opnfv.org/browse/CPERF-3 JIRA to ID which metrics to target, making progress
18:22:34 <dfarrell07> #info dfarrell07 has been working adding NSTAT to tools container, mostly done but not pushed, will push today or weekend
18:23:23 <dfarrell07> #info Jamo has been making progress on getting Jenkins job running on our pod with help from Tim, has the basics running and is doing the normal debugging process now (x installed, y configed, etc)
18:24:17 <dfarrell07> #info dfarrell07 had discussion on Test call about layout of projects related to Functest vs Yardstick, where projects should go. Functest for failures, Yardstick for things that gather metrics. CPerf is under Yardstick.
18:24:41 <dfarrell07> #info OPNFV Summit is in two weeks, dfarrell07, n_anastop, Al will be there
18:24:48 <dfarrell07> #info Marcus is still off doing OpenStack training
18:25:55 <dfarrell07> #info Al discusses idea around having set of expected things/flow we define as deployment (these switches, this # of controllers, etc), param those numbers, work through normal usecases vs driving to max capacity
18:27:55 <dfarrell07> #info LuisGomez and dfarrell07 agree with Al's ~user-story testing style idea, black box, maybe multinet test via NSTAT
18:28:47 <dfarrell07> #info LuisGomez has been working on Bulk-o-Matic tool for ODL. Runs inside controller but accessed via REST API, allows user to say "program a ton of flows", then internal app drives controller to do that from inside
18:29:37 <dfarrell07> #info LuisGomez reports that we get better perf with Bulk-o-Matic test than network restart test we did in whitepaper (as described last week, network restart has some unexpected delay)
18:30:06 <dfarrell07> #info LuisGomez says better perf with Bulk-o-Matic when programming more flows, but same when programming same number of flows (200 vs 100k for example)
18:30:27 <dfarrell07> #info There is info on openflowplugin-dev list about how to use this app, LuisGomez will share with ppl who don't follow that list
18:31:14 <dfarrell07> #info Flow-config-blaster doesn't work well with more than 200 flows from outside REST API
18:32:49 <dfarrell07> #info This Bulk-o-Matic tool maybe isn't good for CPerf because it's not controller agnostic, would need one for each controller (ONOS has a similar thing so that's maybe possible), but again this kinda gets away from the point of common tests
18:33:11 <dfarrell07> #info Agreement overall we should stick with more controller agnostic tests
18:34:09 <dfarrell07> #link https://www.eventscribe.com/2016/OPNFV/aaSearchByDay.asp?h=Full%20Schedule&BCFO=P|G OPNFV Schedule
18:34:13 <dfarrell07> #undo
18:34:13 <collabot`> Removing item from minutes: <MeetBot.ircmeeting.items.Link object at 0x2f34450>
18:34:18 <dfarrell07> #link https://www.eventscribe.com/2016/OPNFV/aaSearchByDay.asp?h=Full%20Schedule&BCFO=P|G OPNFV Summit Schedule
18:35:36 <dfarrell07> #info Al talks about about thinking of tests at higher levels of abstraction, like a connectivity problem, and letting controller (or ppl configuring it) solve that problem the best way it can. Internal layer may be controller-specific, but could still talk about black-box perf and compare
18:38:04 <dfarrell07> #info Could do something with switches already created, then partition network and cause a lot of flows to be programmed. Would be same task for all controllers, would be agnostic via network.
18:38:29 <dfarrell07> #info LuisGomez talks about path programming test that may also work for "authentic" test idea
18:40:41 <dfarrell07> #info n_anastop reports that his team has been experimenting with Flow Config Blaster script
18:41:51 <dfarrell07> #info n_anastop there may be a perf flaw with the test that's introducing extra overhead and may be causing numbers to be reported worse than they actually are
18:42:11 <dfarrell07> #info n_anastop has sent a patch with a proposed correction for this bug, we should review it
18:42:42 <dfarrell07> #info n_anastop has also been working on moving NSTAT host to Docker containers, running each of the hosts in each container, working with Docker compose to maybe solve this
18:43:34 <LuisGomez> #link https://wiki.opendaylight.org/view/Openflow:Testing#Test_Case_3_-_Network_Failure_benchmark
18:45:38 <dfarrell07> #info Al points out that we need to make sure network between containers isn't a bottleneck, we should make sure of this once built
18:47:17 <dfarrell07> #info n_anastop has also been working on latte, has reduced overhead of packet decoding by 45 times, has been working on special impl of decoding OF, go lib he's using doesn't have support, needs access to various fields to impl test
18:50:09 <dfarrell07> #info Practice your German ;)
18:50:12 <dfarrell07> #endmeeting