diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/testing/developer/testscope/index.rst | 8 | ||||
| -rw-r--r-- | docs/testing/user/testspecification/vping/index.rst | 279 | ||||
| -rw-r--r-- | docs/testing/user/userguide/testing_guide.rst | 17 |
3 files changed, 297 insertions, 7 deletions
diff --git a/docs/testing/developer/testscope/index.rst b/docs/testing/developer/testscope/index.rst index ab1577da..09901333 100644 --- a/docs/testing/developer/testscope/index.rst +++ b/docs/testing/developer/testscope/index.rst @@ -400,6 +400,14 @@ Verify high availability of OpenStack controller services | opnfv.ha.tc010.disk_I/O_block | opnfv.ha.tc011.load_balance_service_down +---------------------------------------- +Test Area vPing - Basic VNF Connectivity +---------------------------------------- + +| opnfv.vping.userdata +| opnfv.vping.ssh + + Optional CVP Test Areas ======================== diff --git a/docs/testing/user/testspecification/vping/index.rst b/docs/testing/user/testspecification/vping/index.rst new file mode 100644 index 00000000..d7a207c0 --- /dev/null +++ b/docs/testing/user/testspecification/vping/index.rst @@ -0,0 +1,279 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Ericsson AB + +======================== +Vping test specification +======================== + +.. toctree:: + :maxdepth: 2 + +Scope +===== + +The vping test area evaluates basic NFVi capabilities of the system under test. +These capabilities include creating a small number of virtual machines, +establishing basic L3 connectivity between them and verifying connectivity by +means of ICMP packets. + + +References +========== + +- Neutron Client + + - https://docs.openstack.org/developer/python-neutronclient/usage/library.html + +- Nova Client + + - https://docs.openstack.org/developer/python-novaclient/ref/v2/servers.html + +- SSHClient + + - http://docs.paramiko.org/en/2.2/ + +- SCPClient + + - https://pypi.python.org/pypi/scp + + +Definitions and abbreviations +============================= + +The following terms and abbreviations are used in conjunction with this test +area + +- ICMP - Internet Control Message Protocol +- L3 - Layer 3 +- NFVi - Network functions virtualization infrastructure +- SCP - Secure Copy +- SSH - Secure Shell +- VM - Virtual machine + + +System Under Test (SUT) +======================= + +The system under test is assumed to be the NFVi and VIM in operation on a +Pharos compliant infrastructure. + + +Test Area Structure +=================== + +The test area is structured in two separate tests which are executed +sequentially. The order of the tests is arbitrary as there are no dependencies +across the tests. + + +Test Descriptions +================= + +-------------------------------------------------------------------- +Test Case 1 - vPing using userdata provided by nova metadata service +-------------------------------------------------------------------- + +Short name +---------- + +opnfv.vping.userdata + + +Use case specification +---------------------- + +This test evaluates the use case where an NFVi tenant boots up two VMs and +requires L3 connectivity between those VMs. The target IP is passed to the VM +that will initiate pings by using a custom userdata script provided by nova metadata service. + + +Test preconditions +------------------ + +At least one compute node is available. No further pre-configuration needed. + + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Methodology for verifying connectivity +'''''''''''''''''''''''''''''''''''''' + +Connectivity between VMs is tested by sending ICMP ping packets between +selected VMs. The target IP is passed to the VM sending pings by using a +custom userdata script by means of the config driver mechanism provided by +Nova metadata service. Whether or not a ping was successful is determined by +checking the console output of the source VMs. + + +Test execution +'''''''''''''' + +* Test action 1: + * Create a private tenant network by using neutron client + * Create one subnet and one router in the network by neutron client + * Add one interface between the subnet and router + * Add one gateway route to the router by neutron client + * Store the network id in the response +* **Test assertion 1:** The network id, subnet id and router id can be found in the response +* Test action 2: + * Create an security group by using neutron client + * Store the security group id parameter in the response +* **Test assertion 2:** The security group id can be found in the response +* Test action 3: boot VM1 by using nova client with configured name, image, flavor, private tenant + network created in test action 1, security group created in test action 2 +* **Test assertion 3:** The VM1 object can be found in the response +* Test action 4: Generate ping script with the IP of VM1 to be passed as userdata provided by + the **nova metadata service**. +* Test action 5: Boot VM2 by using nova client with configured name, image, flavor, private tenant + network created in test action 1, security group created in test action 2, userdata created + in test action 4 +* **Test assertion 4:** The VM2 object can be found in the response +* Test action 6: Inside VM2, the ping script is executed automatically when booted and it contains a + loop doing the ping until the return code is 0 or timeout reached. For each ping, when the return + code is 0, "vPing OK" is printed in the VM2 console-log, otherwise, "vPing KO" is printed. + Monitoring the console-log of VM2 to see the response generated by the script. +* **Test assertion 5:** "vPing OK" is detected, when monitoring the console-log in VM2 +* Test action 7: delete VM1, VM2 +* **Test assertion 6:** VM1 and VM2 are not present in the VM list +* Test action 8: delete security group, gateway, interface, router, subnet and network +* **Test assertion 7:** The security group, gateway, interface, router, subnet and network are + no longer present in the lists after deleting + + +Pass / fail criteria +'''''''''''''''''''' + +This test evaluates basic NFVi capabilities of the system under test. +Specifically, the test verifies that: + +* Neutron client network, subnet, router, interface create commands return valid "id" parameters + which are shown in the create response message +* Neutron client interface add command to add between subnet and router returns success code +* Neutron client gateway add command to add to router returns success code +* Neutron client security group create command returns valid "id" parameter which is shown in + the response message +* Nova client VM create command returns valid VM attributes response message +* Nova metadata server can transfer userdata configuration at nova client VM booting time +* Ping command from one VM to the other in same private tenant network returns valid code +* All items created using neutron client or nova client create commands are able to be removed by + using the returned identifiers + +In order to pass this test, all test assertions listed in the test execution +above need to pass. + + +Post conditions +--------------- + +None + + +---------------------------------------------- +Test Case 2 - vPing using SSH to a floating IP +---------------------------------------------- + +Short name +---------- + +opnfv.vping.ssh + + +Use case specification +---------------------- + +This test evaluates the use case where an NFVi tenant boots up two VMs and requires +L3 connectivity between those VMs. An SSH connection is establised from the host to +a floating IP associated with VM2 and ``ping`` is executed on VM2 with the IP of VM1 as target. + + +Test preconditions +------------------ + +At least one compute node is available. There should exist an OpenStack external network +and can assign floating IP. + + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Methodology for verifying connectivity +'''''''''''''''''''''''''''''''''''''' + +Connectivity between VMs is tested by sending ICMP ping packets between +selected VMs. To this end, the test establishes an SSH connection from the host +running the test suite to a floating IP associated with VM2 and executes ``ping`` +on VM2 with the IP of VM1 as target. + + +Test execution +'''''''''''''' + + +* Test action 1: + * Create a private tenant network by neutron client + * Create one subnet and one router are created in the network by using neutron client + * Create one interface between the subnet and router + * Add one gateway route to the router by neutron client + * Store the network id in the response +* **Test assertion 1:** The network id, subnet id and router id can be found in the response +* Test action 2: + * Create an security group by using neutron client + * Store the security group id parameter in the response +* **Test assertion 2:** The security group id can be found in the response +* Test action 3: Boot VM1 by using nova client with configured name, image, flavor, private tenant + network created in test action 1, security group created in test action 2 +* **Test assertion 3:** The VM1 object can be found in the response +* Test action 4: Boot VM2 by using nova client with configured name, image, flavor, private tenant + network created in test action 1, security group created in test action 2 +* **Test assertion 4:** The VM2 object can be found in the response +* Test action 5: create one floating IP by using neutron client, storing the floating IP address + returned in the response +* **Test assertion 5:** Floating IP address can be found in the response +* Test action 6: Assign the floating IP address created in test action 5 to VM2 by using nova client +* **Test assertion 6:** The assigned floating IP can be found in the VM2 console log file +* Test action 7: Establish SSH connection between the test host and VM2 through the floating IP +* **Test assertion 7:** SSH connection between the test host and VM2 is established within + 300 seconds +* Test action 8: Copy the Ping script from the test host to VM2 by using SCPClient +* **Test assertion 8:** The Ping script can be found inside VM2 +* Test action 9: Inside VM2, to execute the Ping script to ping VM1, the Ping script contains a + loop doing the ping until the return code is 0 or timeout reached, for each ping, when the return + code is 0, "vPing OK" is printed in the VM2 console-log, otherwise, "vPing KO" is printed. + Monitoring the console-log of VM2 to see the response generated by the script. +* **Test assertion 9:** "vPing OK" is detected, when monitoring the console-log in VM2 +* Test action 10: delete VM1, VM2 +* **Test assertion 10:** VM1 and VM2 are not present in the VM list +* Test action 11: delete floating IP, security group, gateway, interface, router, subnet and network +* **Test assertion 11:** The security group, gateway, interface, router, subnet and network are + no longer present in the lists after deleting + +Pass / fail criteria +'''''''''''''''''''' + +This test evaluates basic NFVi capabilities of the system under test. +Specifically, the test verifies that: + +* Neutron client network, subnet, router, interface create commands return valid "id" parameters + which are shown in the create response message +* Neutron client interface add command to add between subnet and router return success code +* Neutron client gateway add command to add to router return success code +* Neutron client security group create command returns valid "id" parameter which is shown in the + response message +* Nova client VM create command returns valid VM attributes response message +* Neutron client floating IP create command return valid floating IP address +* Nova client add floating IP command returns valid response message +* SSH connection can be established using a floating IP +* Ping command from one VM to another in same private tenant network returns valid code +* All items created using neutron client or nova client create commands are able to be removed by + using the returned identifiers + +In order to pass this test, all test assertions listed in the test execution +above need to pass. + + +Post conditions +--------------- + +None diff --git a/docs/testing/user/userguide/testing_guide.rst b/docs/testing/user/userguide/testing_guide.rst index 4f08a064..2d45b189 100644 --- a/docs/testing/user/userguide/testing_guide.rst +++ b/docs/testing/user/userguide/testing_guide.rst @@ -261,8 +261,8 @@ If the Test Host is online, you can directly pull. .. code-block:: bash - $ sudo docker pull opnfv/dovetail:cvp.0.3.0 - cvp.0.3.0: Pulling from opnfv/dovetail + $ sudo docker pull opnfv/dovetail:cvp.0.4.0 + cvp.0.4.0: Pulling from opnfv/dovetail 30d541b48fc0: Pull complete 8ecd7f80d390: Pull complete 46ec9927bb81: Pull complete @@ -275,9 +275,9 @@ If the Test Host is online, you can directly pull. bf7c644692de: Pull complete cdc345e3f363: Pull complete Digest: sha256:d571b1073b2fdada79562e8cc67f63018e8d89268ff7faabee3380202c05edee - Status: Downloaded newer image for opnfv/dovetail:cvp.0.3.0 + Status: Downloaded newer image for opnfv/dovetail:cvp.0.4.0 -An example of the <tag> is *cvp.0.3.0*. +An example of the <tag> is *cvp.0.4.0*. If the Test Host is offline, you will need to first pull the Dovetail Docker image, and all the dependent images that Dovetail uses, to a host that is online. The reason that you need @@ -287,9 +287,10 @@ offline, then all these dependencies will also need to be manually copied. .. code-block:: bash - $ sudo docker pull opnfv/dovetail:cvp.0.3.0 + $ sudo docker pull opnfv/dovetail:cvp.0.4.0 $ sudo docker pull opnfv/functest:cvp.0.2.0 $ sudo docker pull opnfv/yardstick:danube.3.1 + $ sudo docker pull opnfv/bottlenecks:cvp.0.4.0 $ sudo wget -nc http://artifacts.opnfv.org/sdnvpn/ubuntu-16.04-server-cloudimg-amd64-disk1.img -P {ANY_DIR} Once all these images are pulled, save the images, copy to the Test Host, and then load @@ -299,7 +300,8 @@ At the online host, save images. .. code-block:: bash - $ sudo docker save -o dovetail.tar opnfv/dovetail:cvp.0.3.0 opnfv/functest:cvp.0.2.0 opnfv/yardstick:danube.3.1 + $ sudo docker save -o dovetail.tar opnfv/dovetail:cvp.0.4.0 opnfv/functest:cvp.0.2.0 \ + opnfv/yardstick:danube.3.1 opnfv/bottlenecks:cvp.0.4.0 Copy dovetail.tar file to the Test Host, and then load the images on the Test Host. @@ -316,8 +318,9 @@ Now check to see that the Dovetail image has been pulled or loaded properly. $ sudo docker images REPOSITORY TAG IMAGE ID CREATED SIZE opnfv/functest cvp.0.2.0 9eaeaea5f203 8 days ago 1.53GB - opnfv/dovetail cvp.0.3.0 5d25b289451c 8 days ago 516MB + opnfv/dovetail cvp.0.4.0 5d25b289451c 8 days ago 516MB opnfv/yardstick danube.3.1 574596b6ea12 8 days ago 1.2GB + opnfv/bottlenecks cvp.0.4.0 00450688bcae 3 hours ago 622 MB Regardless of whether you pulled down the Dovetail image directly online, or loaded from a static image tar file, you are ready to run Dovetail. |