-----BEGIN RSA PRIVATE KEY-----
-MIIEpQIBAAKCAQEAxYmqpbNeM7MT0o0D2wpFSuGHQThXzSods3QxL5x7r6A1Gs2t
-VNoZEkBGtymyeD85NPA5SBYErUFs+5+h09j64a5n+s7zJ17v6WPSvz3gXsQmcsKc
-VVsn+0KI7TJUsv/HPTT9yICXN8mbePp0SoNWwr9dZbFlBGcELDFghT91JuQekN5T
-wsqaRMmRZ/rwj3dpsnFYJNMc9r+wPUbDletZowgdvddsoWUmof4TMxKLCLiiCzzS
-TgVhuf0eb1VdCoV3miTg/sE5pSE/jLIGHIzZzXp1ShckUCZXfJzfoBuTDde30Wdk
-+XtX4xhwifnIocfkeI2L3VIDX7RVtaS2+GSvEwIDAQABAoIBAQCIn/73PGgbOfCr
-3/yasy/Z6sKxyVZxAIAqbmLWm1Sw1A3my/rmhTJx/SLr7FsT8CaRBtWXliMF8gp+
-vpoe/CQJk6c3QYvL303wDqrkutdEtEYjeZbHMpUko5Aw/m62n1Iec1hUJRxx6W8u
-7YshPlXzvIfMnjVQJjAsoLoxbwKIMmgYmRytO2W5hPnM/o5VO6lLHur1jEsHt6df
-BgMy2mrKeec4AlIr88+ni4ayDSjdE2C2l+x3lLRz75Wrv5iWAOj99hnpY5ChOU9g
-y0aJTmQ5iZLSSbpQ7UPYbkrv2jERd+HXTntVaEetf6cwnGyyjrOGy0BxxzPHjPW3
-ux85RCUBAoGBAOPEwbDnseune7+Dkz1DhdicBkV/9bB32B77Yt7XpjsMJZGko+44
-4mQZvRddWfHx9hr3p+MpYFD71pugO0qfxRcZIC3UhvltlD9Ez7ZC8HO45OKxhSIm
-xHoHSXRLgF3YBTgjoUXLZns/+bu8J63ZbfbYg1jTTkQcEccLCXyKu+3JAoGBAN4F
-qqhsLLnh1Fo9XbJIAGUKzirWEnbGRtDV66b5j90MVMHanZ0NHpJN5/xM44ymuvMY
-Un/oi+BZdm2wtb5wB3+vj4tRR2MpIHiWh9ELSHcGI3bJkR+9oEeDUfRVB3VNcmxv
-mhmONTp+B4v1SghDivYWmo86C3ysXLi/1klnZ7P7AoGBAM2T+X7CoUQhlv/0siDJ
-oTUxHjf8lrUAdoEAROz9l3wUKpSaFZwem7fdw14jU9ucmJUektnlrplptPoiVWG1
-cx61/uVevbTDwtqYMSJAqObKK0yxDYkVlKDPkuz0eJg7MfrJrfZg786un6li2i1/
-4lC6e1Lg5fNzolgVDirqzVSBAoGAR1ekzffsq1JQzSp46CfQ0KcXNpaRWk8+RC7p
-ST9aJhqnRZ99FBE6KKMWD3GZkQGmgyTmpalRASdeMcMds3MGRdZhFtBoUwnNIFKm
-k9q/T1fOn4YHtx5U2YXuGMgV3HClewiliN60ZfZHcIbCYkNp7Me4pJtvQ4GTTd5+
-+hlbLm8CgYEAsQA3/qFgS9/QF+IZ/7fgv5wMuGJOF607sM43O8Fxz1KFAYLQaL8T
-jIrFCNvqmNHf8bYPBWt0/jo6+rov8avWUvffeqrEuKIgqW0068HUyeU9rKdYNgw7
-XjU0R0K16I9GQjYQph2IZlJaWBXuRZKrO7Nhqw/ck6ANzhKcJ114suA=
+MIIEogIBAAKCAQEAzVkXQaXre1h1FmIOAPwgBst5y5crMVI6dSPIBqo0sLU4tCG7
+WdpZCYlyymj64gjOrHNT0rwX5t0YRywzh9mzOej5PDPBpS4uWxnb+jRpoy/m7fKp
+HDJgas8RWhRJ6CSMoCfD7ZxvEPnhHVNpgscKipE8ivoY173T9dGothiY48Z6430g
+NoLLIHiunL4lUyeBwZ9Sn6rLdHkL558wlxpiNbnaxCSIKywmuH3KiAVTQhAWGNQp
+a4BU4hP844tFiTVT7+oySHhEZokvBlE1RTc199s752tyEN1eBQGycsWw3csJ6Eth
+bwVWlKaGzJkTc+jcoOX420easK2Jrkha8Jk05QIDAQABAoIBAHuhlNfobiMf+baV
+KHs9UIbmwJhrlgymxh06grZIiVqOcOo6mNKbHBoaz6q/k7S8urmm4aOxrO5I1NIc
+8ZVr43UNJ+kv+/lYGX6tzfwQzDz8nRtLirc4OUZ1DqxeJLUINEZESrjnAxOEbh06
+1/5tmZIdqQa/Vm+lkVSheuLPYlVXWDPhJNhYZlAfbR6TiRnEmLnuTiuV4KHbuT9u
+OpeB2PBGFF7qmlAFKMHTNQ/tMQvKZqZCD+u49spN33XJ7vp18WjCjlfYf7l5ysTX
+BqOtIaqp/mCi/o45u3OWVG2R4JUEAVEYYjohS7BSs8pqpeyGDGOOykYP3Tl1zakt
+CXReZWECgYEA+F/oOfH3bBu/tR4vjl7faFJaiJxqgwzg1NlmE9b9S4NSb2DQuv98
+o74kf61MiMg8XcuuJzkpbEze8BJUsacMtlHWI5G1KMgUfLYhjqE/YRZj9eUO/Cb/
+pSWzHOSC1Tbz9FRP6+8DcHB/TWRId8iX6RRsFWBA/fGflISY2l01E+kCgYEA06cE
+axalbEonNJZ2F8Dnj2DBMoKmkODQw7JSqYYgePiSiPlBBFkCGzUu0nrxduWIXVPp
+MdcIlm+B2C6CWNA9Na4x6I+5cy6ku4+lt8Oz59pqY0x909iyYJ6SA8GeaQcPnoVu
+c5h/G2eA3oc6SxsMK/22GwNR55CPkAva9+A3p50CgYAEXLLYaa59wJMCXFBbgMEN
+tPyQD6czPAOq2VKYoJr8O4c0G5Au6JPI0GsVrvZ8JIAi6ZPabn+Svlrf/oJsSFHJ
+1fAb2dBDshfiBNTcC2rwipMg23AC77BntxzJMh42Hmv0a5Knwx/dVqx1sIAxUl2Q
+o2Iuke0ySI8T7aw9kYuAGQKBgGLR3U8+sJfh+3IjOhoXGEaqTyoNNEX6oZ5teQjr
+teelb42CiyfDgyc+6pCdlHYF72hb0EpT8w+CGqbb+EINYDbbETRbPqQXyBRGmoI1
+Xp9HLFsWkL1DtO1FvDkCwrqY8GL8O7i/H8GkzteXXdFJXKKBf/AW2bv7k/wWfPM0
+/edFAoGAR2QJQpvz/qAa64SndY32jYB9KMIb8aZJ7xe11+MgljFJ93MK1rsOtBXP
+hbxoRaQUMw8MyuadOrUiK8vUNuFzRa/JNKB23bVb9fhMgbNkRYauJjj7Pl/KlxEs
+azwNk2nziRpd3qWhvU1rAjFGUs6vjzMFQsJPXFGs+hnZTObH+6A=
-----END RSA PRIVATE KEY-----
--- /dev/null
+..\r
+ TODO As things will change, then this document has to be revised before the\r
+ next release. Steps:\r
+ 1. Verify that the instructions below are correct and have not been changed.\r
+ 2. Add everything that is currently missing and should be included in this document.\r
+ 3. Make sure each title has a paragraph or an introductory sentence under it.\r
+ 4. Make sure each sentence is grammatically correct and easily understandable.\r
+ 5. Remove this comment section.\r
+\r
+Guide to run QTIP:\r
+==================\r
+\r
+This guide will serve as a first step to familiarize the user with how to \r
+run QTIP the first time when the user clones QTIP on to their host machine. \r
+In order to clone QTIP please follow the instructions in the \r
+installation.rst located in docs/userguide/installation.rst. \r
+\r
+QTIP Directory structure:\r
+-------------------------\r
+\r
+The QTIP directory has been sectioned off into multiple folders to facilitate\r
+ segmenting information into relevant categories. The folders that concern\r
+ the end user are `test_cases/` and `test_list/`.\r
+\r
+test_cases/:\r
+------------\r
+\r
+This folder is used to store all the config files which are used to setup the\r
+ environment prior to a test. This folder is further divided into opnfv pods \r
+ which run QTIP. Inside each pod there are folders which contain the config \r
+ files segmented based on test cases. Namely, these include, `Compute`,\r
+ `Network` and `Storage`. The default folder is there for the end user who \r
+ is interested in testing their infrastructure but arent part of a opnfv pod.\r
+\r
+The structure of the directory for the user appears as follows\r
+::\r
+\r
+ test_cases/default/compute\r
+ test_cases/default/network\r
+ test_cases/default/storage\r
+\r
+The benchmarks that are part of the QTIP framework are listed under these \r
+folders. An example of the compute folder is shown below. \r
+Their naming convention is <BENCHMARK>_<VM/BM>.yaml\r
+::\r
+\r
+ dhrystone_bm.yaml\r
+ dhrystone_vm.yaml\r
+ whetstone_vm.yaml\r
+ whetstone_bm.yaml\r
+ ssl_vm.yaml\r
+ ssl_bm.yaml\r
+ ramspeed_vm.yaml\r
+ ramspeed_bm.yaml\r
+ dpi_vm.yaml\r
+ dpi_bm.yaml\r
+\r
+The above listed files are used to configure the environment. The VM/BM tag \r
+distinguishes between a test to be run on the Virtual Machine or the compute \r
+node itself, respectively.\r
+\r
+\r
+test_list/:\r
+-----------\r
+\r
+This folder contains three files, namely `compute`, `network` and `storage`. \r
+These files list the benchmarks are to be run by the QTIP framework. Sample \r
+compute test file is shown below\r
+::\r
+\r
+ dhrystone_vm.yaml\r
+ dhrystone_bm.yaml\r
+ whetstone_vm.yaml\r
+ ssl_bm.yaml\r
+\r
+The compute file will now run all the benchmarks listed above one after \r
+another on the environment. `NOTE: Please ensure there are no blank lines \r
+in this file as that has been known to throw an exception`.\r
+\r
+Preparing a config file for test:\r
+---------------------------------\r
+\r
+We will be using dhrystone as a example to list out the changes that the \r
+user will need to do in order to run the benchmark.\r
+Dhrystone on Compute Nodes:\r
+^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
+\r
+QTIP framework can run benchmarks on the actual compute nodes as well. In \r
+order to run dhrystone on the compute nodes we will be editing the \r
+dhrystone_bm.yaml file.\r
+\r
+::\r
+\r
+ Scenario:\r
+ benchmark: dhrystone\r
+ host: machine_1, machine_2\r
+ server:\r
+\r
+The `Scenario` field is used by to specify the name of the benchmark to \r
+run as done by `benchmark: dhrystone`. The `host` and `server` tag are \r
+not used for the compute benchmarks but are included here to help the \r
+user `IF` they wish to control the execution. By default both machine_1 \r
+and machine_2 will have dhrystone run on them in parallel but the user \r
+can change this so that machine_1 run dhrystone before machine_2. This \r
+will be elaborated in the `Context` tag.\r
+\r
+::\r
+\r
+ Context:\r
+ Host_Machines:\r
+ machine_1:\r
+ ip: 10.20.0.6\r
+ pw:\r
+ role: host\r
+ machine_2:\r
+ ip: 10.20.0.5\r
+ pw:\r
+ role: host\r
+\r
+ Virtual_Machines:\r
+\r
+The `Context` tag helps the user list the number of compute nodes they want\r
+ to run dhrystone on. The user can list all the compute nodes under the \r
+ `Host_Machines` tag. All the machines under test must be listed under the \r
+ `Host_Machines` and naming it incrementally higher. The `ip:` tag is used \r
+ to specify the IP of the particular compute node. The `pw:` tag can be left \r
+ blank because QTIP uses its own key for ssh. In order to run dhrystone on \r
+ one compute node at a time the user needs to edit the `role:` tag. `role: \r
+ host` for machine_1 and `role: server` for machine_2 will allow for \r
+ dhrystone to be run on machine_1 and then run on machine_2.\r
+\r
+::\r
+\r
+\r
+ Test_Description:\r
+ Test_category: "Compute"\r
+ Benchmark: "dhrystone"\r
+ Overview: >\r
+ ''' This test will run the dhrystone benchmark in parallel on \r
+ machine_1 and machine_2.\r
+\r
+The above field is purely for a description purpose to explain to the user \r
+the working of the test and is not fed to the framework. \r
+\r
+Sample dhrystone_bm.yaml file:\r
+------------------------------\r
+::\r
+\r
+ Scenario:\r
+ benchmark: dhrystone\r
+ host: machine_1, machine_2\r
+ server:\r
+\r
+ Context:\r
+ Host_Machines:\r
+ machine_1:\r
+ ip: 10.20.0.6\r
+ pw:\r
+ role: host\r
+ machine_2:\r
+ ip: 10.20.0.5\r
+ pw:\r
+ role: host\r
+\r
+ Virtual_Machines:\r
+\r
+\r
+ Test_Description:\r
+ Test_category: "Compute"\r
+ Benchmark: "dhrystone"\r
+ Overview: >\r
+ ''' This test will run the dhrystone benchmark in parallel on \r
+ machine_1 and machine_2.\n\r
+\r
+Dhrystone on Virtual Machine:\r
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
+To run dhrystone on the VMs we will be editing dhrystone_vm.yaml file. \r
+Snippets on the file are given below.\r
+\r
+::\r
+\r
+ Scenario:\r
+ benchmark: dhrystone\r
+ host: virtualmachine_1, virtualmachine_2\r
+ server: \r
+\r
+\r
+The `Scenario` field is used by to specify the name of the benchmark to \r
+run as done by `benchmark: dhrystone`. The `host` and `server` tag are \r
+not used for the compute benchmarks but are included here to help the \r
+user `IF` they wish to control the execution. By default both \r
+virtualmachine_1 and virtualmachine_2 will have dhrystone run on them \r
+in parallel but the user can change this so that virtualmachine_1 run \r
+dhrystone before virtualmachine_2. This will be elaborated in the \r
+`Context` tag.\r
+::\r
+\r
+ Context:\r
+ Host_Machines:\r
+\r
+ Virtual_Machines: \r
+ virtualmachine_1:\r
+ availability_zone: compute1\r
+ public_network: 'net04_ext'\r
+ OS_image: QTIP_CentOS\r
+ flavor: m1.large\r
+ role: host\r
+ virtualmachine_2:\r
+ availability_zone: compute2\r
+ public_network: 'net04_ext'\r
+ OS_image: QTIP_CentOS\r
+ flavor: m1.large\r
+ role: host\r
+\r
+The `Context` tag helps the user list the number of VMs and their \r
+characteristic. The user can list all the VMs they want to bring up \r
+under the `Virtual_Machines:` tag. In the above example we will be \r
+bringing up two VMs. One on Compute1 and the other on Compute2. The \r
+user can change this as desired `NOTE: Please ensure you have the \r
+necessary compute nodes before listing under the 'availability_zone:' \r
+tag`. The rest of the options do not need to be modified by the user.\r
+\r
+Running dhrystone sequentially (Optional):\r
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r
+\r
+In order to run dhrystone on one VM at a time the user needs to edit \r
+the `role:` tag. `role: host` for virtualmachine_1 and `role: server` \r
+for virtualmachine_2 will allow for dhrystone to be run on \r
+virtualmachine_1 and then run on virtualmachine_2.\r
+\r
+::\r
+\r
+ Test_Description:\r
+ Test_category: "Compute"\r
+ Benchmark: "dhrystone"\r
+ Overview: \r
+ This test will run the dhrystone benchmark in parallel on \r
+ virtualmachine_1 and virtualmachine_2\r
+\r
+The above field is purely for a decription purpose to explain to \r
+the user the working of the test and is not fed to the framework.\r
+\r
+Sample dhrystone_vm.yaml file:\r
+------------------------------\r
+::\r
+\r
+ Scenario:\r
+ benchmark: dhrystone\r
+ host: virtualmachine_1, virtualmachine_2\r
+ server: \r
+\r
+ Context:\r
+ Host_Machines:\r
+\r
+ Virtual_Machines: \r
+ virtualmachine_1:\r
+ availability_zone: compute1\r
+ public_network: 'net04_ext'\r
+ OS_image: QTIP_CentOS\r
+ flavor: m1.large\r
+ role: host\r
+ virtualmachine_2:\r
+ availability_zone: compute2\r
+ public_network: 'net04_ext'\r
+ OS_image: QTIP_CentOS\r
+ flavor: m1.large\r
+ role: host\r
+ \r
+ Test_Description:\r
+ Test_category: "Compute"\r
+ Benchmark: "dhrystone"\r
+ Overview: >\r
+ This test will run the dhrystone benchmark in parallel on \r
+ machine_1 and machine_2.\n\r
--- /dev/null
+NETWORK THROUGHPUT TESTCASE\r
+\r
+QTIP uses IPerf3 as the main tool for testing the network throughput.\r
+There are two tests that are run through the QTIP framework. \r
+\r
+Network Throughput for VMs\r
+Network Throughput for Compute Nodes\r
+\r
+For the throughout of the compute nodes we simply go into the systems-under-test \r
+and install iperf3 on the nodes. One of the SUTs is used a server and the other as a \r
+client. The client pushes traffic to the server for a duration specified by the user\r
+configuration file for iperf. These files can be found in the test_cases/{POD}/network/\r
+directory. The bandwidth is limited only by the physical link layer speed available to the server.\r
+The result file inlcudes the b/s bandwidth and the CPU usage for both the client and server.\r
+\r
+For the VMs we are running two topologies through the framework.\r
+\r
+1: VMs on the same compute nodes\r
+2: VMs on different compute nodes\r
+\r
+QTIP framework sets up a stack with a private network, security groups, routers and attaches the VMs to this network. Iperf3 is installed\r
+on the VMs and one is assigned the role of client while other serves as a server. Traffic is pushed\r
+over the QTIP private network between the VMs. A closer look in needed to see how the traffic actually\r
+flows between the VMs in this configuration to understand what is happening to the packet as traverses\r
+the openstack network.\r
+\r
+The packet originates from VM1 and its sent to the linux bridge via a tap interface where the security groups\r
+are written. Afterwards the packet is forwarded to the Integration bridge via a patch port. Since VM2 is also connected\r
+to the Integration bridge in a similar manner as VM1 so the packet gets forwarded to the linux bridge connecting\r
+VM2. After the linux bridge the packet is sent to VM2 and is recieved by the Iperf3 server. Since no physical link is\r
+involved in this topology, only the OVS (Integration bridge) is being benchmarked and we are seeing bandwidth in the range\r
+of 14-15 Gbps.\r
+\r
+For the topology where the VMs are spawned on different compute nodes, the path the packet takes becomes more cumbersome.\r
+The packet leaves a VM and makes its way to the Integration Bridge as in the first topology however the integration bridge \r
+forwards the packet to the physical link through the ethernet bridge. The packet then gets a VLAN/Tunnel depending on the network\r
+and is forwarded to the particular Compute node where the second VM is spwaned. The packets enter the compute node through the physical\r
+ethernet port and makes its way to the VM through the integration bridge and linux bridge. As seen here the path is much more involved\r
+even when discussed without the mention of overheads faced at all the internfaces so we are seeing the results in the range of 2 Gbps.\r
+\r
+\r
+
\ No newline at end of file
Code Review / qtip.git / commitdiff