08:31:59 <kubi001> #startmeeting Yardstick Work Meeting
08:31:59 <collabot> Meeting started Mon Apr 17 08:31:59 2017 UTC.  The chair is kubi001. Information about MeetBot at http://wiki.debian.org/MeetBot.
08:31:59 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
08:31:59 <collabot> The meeting name has been set to 'yardstick_work_meeting'
08:32:06 <kubi001> #topic roll call
08:32:08 <kubi001> #info kubi
08:32:13 <rbbratta> #info Ross
08:32:29 <JackChan> #info jack
08:32:38 <Kanglin> #info Kanglin
08:32:44 <JingLu> #info JingLu
08:33:03 <Mingjiang> #info Rex
08:33:08 <kubi001> kalyan: ping
08:33:28 <kubi001> #topic action items follow up
08:33:32 <kubi001> #link http://ircbot.wl.linuxfoundation.org/meetings/opnfv-yardstick/2017/opnfv-yardstick.2017-04-10-08.32.html
08:33:46 <kubi001> #info AP1: Kubi will try to book a time slot of room for this plugfest
08:33:57 <kalyan> Hi all :)
08:34:16 <kalyan> #info kalyan
08:34:44 <kubi001> #info AP1: Done https://wiki.opnfv.org/pages/viewpage.action?pageId=9569132
08:35:38 <kubi001> #info kubi have booked the serveral time slots for yardstick,  one for E-planning, two for integration with Ixia
08:35:53 <kubi001> kalyan: will you attend the plugfest
08:36:24 <kalyan> kubi001: no, i am not attending. Yunhong will
08:36:46 <kubi001> #info Yunhong Jiang from KVM4NFV will attend the plugfest
08:36:51 <kubi001> kalyan: thanks
08:37:27 <kubi001> rbbratta: are the time slots suitable for you?
08:37:41 <kubi001> rbbratta: I mean the plugfest yardstick time slot
08:37:49 <rbbratta> yes
08:38:03 <kubi001> rbbratta: great
08:38:23 <kubi001> please let me know if any time slot you want to change
08:38:38 <kubi001> #info AP2: yardstick team to review flavor create in heat context and feedback
08:38:58 <rbbratta> Martin was working on an update, I just updated the Jira with the new spec.
08:39:44 <kubi001> #info AP2: Done Martin was working on an update, Ross just updated the Jira with the new spec.
08:39:54 <kubi001> thanks for your work
08:39:55 <rbbratta> it will support inline flavor definition, and re-using flavors
08:40:21 <kubi001> #topic agenda for todya
08:40:24 <kubi001> #undo
08:40:24 <collabot> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x248a290>
08:40:32 <kubi001> #topic agenda for today
08:40:34 <Mingjiang> that would be great
08:40:56 <kubi001> #link https://wiki.opnfv.org/display/yardstick/Meetings
08:41:31 <kubi001> #topic PTL election process
08:41:57 <kubi001> #link https://etherpad.opnfv.org/p/yardstick_ptl_election
08:42:30 <kubi001> #info kubi have initialized the etherpad for ptl election process
08:43:51 <kubi001> #action all, please review the ptl election process and give comment, we will finalize the process at plugfest
08:44:10 <kubi001> #topic E-planning
08:44:21 <kubi001> #link https://etherpad.opnfv.org/p/yardstick_release_e
08:45:08 <kubi001> I forwarded the email from kalyan to everyone
08:45:32 <kubi001> they have some requirements for yardstick framework
08:45:55 <kubi001> I guess we can put that into E-release to implenment
08:46:22 <rbbratta> there is also the proposed NFVBench project
08:47:15 <rbbratta> whatever NFVbench does will probably impact what we do for yardstick.
08:48:13 <rbbratta> we also need to discuss scale-out and scale-up tests
08:48:36 <kubi001> rbbratta: yes, good point
08:49:39 <Mingjiang> scale-out and scale-up tests +1
08:50:21 <rbbratta> or anything with dynamic contexts, unless we can use bottlenecks to do scaling
08:50:22 <Mingjiang> for NFVbench, we may need a discuss among yardstick team
08:50:32 <kubi001> rbbratta: what's your idea for NFVBench, From my view, I think we should let the yardstick be reused
08:51:15 <rbbratta> it really depends what the code looks like.  If they aren't using Heat, and what they do for scale-out.
08:52:01 <rbbratta> and also what it does that VSPerf doesn't do.  We had planned to integrate with VSPerf
08:52:43 <rbbratta> I see yardstick as using Heat to bridge the gap until we have some MANO.  I don't see yardstick doing tests that don't use Heat.
08:52:57 <rbbratta> but if Heat is insufficient for NFVbench
08:54:46 <kubi001> I remembered that the evolution of VSperf should be data plane benchmarking, right?
08:55:30 <kubi001> https://wiki.opnfv.org/display/testing/TestPerf?preview=/https%3A%2F%2Fwiki.opnfv.org%2Fdownload%2Fattachments%2F8688867%2FOPNFVTestEcosystem%2528Danube-v02%2529.png%3Fversion%3D1%26modificationDate%3D1488487829000%26api%3Dv2
08:55:39 <rbbratta> yes, without Openstack,  NFVbench is supposed to be with Openstack.  That is good.
08:56:13 <rbbratta> Openstack usually uses double-briding, br-int and br-tun, which I don't think VSPerf usually does.
08:57:47 <rbbratta> I think probably NFVbench doesn't use Heat, but does manual config of VMs and Neutron to ensure correctness and reproducability.
08:59:15 <rbbratta> anyway, we will see
09:00:19 <Mingjiang> yes, we miss the details, now just with the proposal
09:01:01 <Mingjiang> do nfvbench go to this thursday tech-discuss meeting?
09:01:52 <rbbratta> april 20th
09:02:05 <kubi001> yes, one idea from me is that we should try to clarify with them and try to reuse the existing projects
09:02:46 <rbbratta> I'm sure both VSperf and yardstick would like to re-use.
09:03:37 <kubi001> yes
09:03:38 <Mingjiang> +1
09:04:10 <kubi001> kalyan: would you like to discuss your requirements now or with email?
09:05:51 <kalyan> kubi001: will discuss now, atleast what we need..then after an internal kvm discussion will share full details in an email
09:06:35 <kubi001> kalyan: OK, go ahead
09:08:02 <kubi001> 1.  post-execute script
09:08:03 <kalyan> yes, so as mentioned https://etherpad.opnfv.org/p/yardstick_release_e first requirement is ..we need an option in yardstick to be implemented for executing some post execution scripts
09:09:01 <kubi001> kalyan: so the key point is that you need the post-execute script run after context undeploy, right?
09:09:35 <kalyan> this is required because, as a part of kernel debugging we need trace to be disabled soon after the test execution..so that we will avoid unwanted logs for effective debugging
09:09:43 <kalyan> kubi001: yes, exactly
09:11:17 <kubi001> rbbratta:  what's your opinion?
09:11:32 <rbbratta> the script runs on the nodes?
09:12:05 <kalyan> rbbratta: yes, runs on the nodes
09:12:53 <rbbratta> I think we just added a teardown script section on node.py
09:13:09 <kalyan> so basically, we need post-execute script option..if required we wil pass the script as an argument to the yaml file ..
09:13:12 <rbbratta> which I update for ansible scripts.
09:14:34 <rbbratta> Jing Lu added for https://jira.opnfv.org/browse/YARDSTICK-573
09:15:04 <rbbratta> env: setup: - node1: script: ....
09:15:15 <rbbratta> that should already work.
09:15:34 <JingLu> the  node context  now supoort run config on nodes
09:15:46 <rbbratta> I'd prefer ansible playbooks over shell scripts, but it depends on the shell script.
09:16:16 <rbbratta> JingLu: do we have a better example that uses 'teardown'?
09:17:31 <JingLu> Here is a context example for cpu pinning test
09:17:35 <JingLu> contexts:
09:17:35 <JingLu> -
09:17:36 <JingLu> type: Node
09:17:36 <JingLu> name: env-prepare
09:17:38 <JingLu> file: {{file}}
09:17:38 <JingLu> env:
09:17:40 <JingLu> type: ansible
09:17:40 <JingLu> setup: cpu_pin_setup.yaml
09:17:42 <JingLu> teardown: cpu_pin_teardown.yaml
09:19:18 <JingLu> you can specify setup and teardown ansible playbook yaml in the env section
09:20:28 <JingLu> The post-execute script needs to be implemented using ansible
09:22:56 <JackChan> contexts:
09:22:56 <JackChan> -
09:22:56 <JackChan> type: Node
09:22:58 <JackChan> name: LF
09:23:00 <JackChan> file: {{ file }}
09:23:02 <JackChan> env:
09:23:04 <JackChan> type: ansible
09:23:06 <JackChan> setup: migrate_setup.yaml
09:23:08 <JackChan> teardown: migrate_teardown.yaml
09:23:10 <JackChan> -
09:23:12 <JackChan> name: migrate
09:23:14 <JackChan> image: yardstick-image
09:23:16 <JackChan> flavor: {{ flavor }}
09:23:18 <JackChan> user: ubuntu
09:23:20 <JackChan> placement_groups:
09:23:22 <JackChan> pgrp1:
09:23:24 <JackChan> policy: "availability"
09:23:26 <JackChan> servers:
09:23:28 <JackChan> jack:
09:23:30 <JackChan> floating_ip: true
09:23:32 <JackChan> placement: "pgrp1"
09:23:34 <JackChan> rose:
09:23:36 <JackChan> placement: "pgrp1"
09:23:38 <JackChan> floating_ip: true
09:23:40 <JackChan> networks:
09:23:42 <JackChan> test:
09:23:44 <JackChan> cidr: '10.0.1.0/24'
09:23:48 <JackChan> This is an example.
09:24:07 <JingLu> Yes I think we can orchestate a "node" type context after the "heat" type context to do the post-execute action
09:24:09 <JackChan> it will use ansible playbook to execute migrate_teardown.yaml after undeploy the stack.
09:28:26 <JackChan> The contexts is a stack. So when setup it will first deploy context1 then context2, when teardown it will first undeploy context2 then context1.
09:30:02 <Mingjiang> since the context is undeployed in a reverse way, so you need to add Node context with teardown in at the top?
09:30:21 <JackChan> Mingjiang: yes
09:30:53 <kubi001> kalyan: Is that make sense for you?
09:31:52 <Mingjiang> I think this solution requires that the post-execute script should be run on the node.
09:32:58 <kalyan> kubi001: yes, I am actually new to these terminologies, what i understood is under node context 'file:' option will be provided to execute the script..right?
09:34:35 <JackChan> kalyan: the file is nodes config. actually it will execute the migrate_teardown.yaml using ansible.
09:36:04 <kalyan> Jackchan: thanks for clarfying that, just to mention the post execute script we will be executing is a shell script..
09:37:39 <JackChan> kalyan: it also support execute script by set the type keyword to 'script' in env.
09:38:05 <Mingjiang> does this shell scripts run on some specific nodes?
09:38:18 <kalyan> yardstick -d task start cylictest-node-context.yaml with this command we need an option to execute some scripts which we pass....
09:38:59 <kalyan> yes, those will be run on nodes depending on the type of job verify/daily
09:40:31 <JackChan> kalyan: maybe I can send you an email to clarify it. What's your email address?
09:41:09 <kalyan> JackChan: sure, thanks reddyx.gundarapu@intel.com
09:41:36 <JackChan> kalyan: ok
09:41:55 <kubi001> #action JackChan will clarify the technical detail for kalyan's requiremetn with email
09:43:33 <kubi001> kalyan: As the time is quite over, About 2nd requirement, I think we can discuss in etherpad page,
09:43:58 <kalyan> sorry if any confusion caused, will discuss again on this point after getting some clarification from Jackchan mail.
09:44:26 <kalyan> https://gerrit.opnfv.org/gerrit/#/c/33407/
09:44:44 <kubi001> kalyan: sure, will do
09:44:49 <kalyan> kubi001: this will do the second point i think
09:45:18 <kalyan> but i will wait for some inputs from yunhong, to check if he is ok or if something else to be added as well
09:47:01 <kalyan> kubi001: sure, will discuss in etherpad page if needed..
09:47:56 <kubi001> #action please discuss the detail with the etherpad page https://etherpad.opnfv.org/p/yardstick_release_e
09:48:45 <kubi001> #topic Aob
09:48:51 <kubi001> anything else?
09:49:23 <rbbratta> I updated the ansible code, using some existing code from other project.
09:49:48 <kubi001> rbbratta: thanks
09:49:58 <rbbratta> https://gerrit.opnfv.org/gerrit/#/c/33411/
09:50:29 <rbbratta> still trying to get providers networks working.
09:50:55 <rbbratta> Deepak I think is still working on Ixia code, but that may wait until plugfest when we meet with the Ixia people.
09:51:13 <rbbratta> that's it from my side.
09:52:16 <kubi001> thanks for for today' s meeting
09:52:22 <kubi001> #endmeeting