From 16e36edaec487300f1dd154110077d499bf7726e Mon Sep 17 00:00:00 2001 From: Georg Kunz Date: Thu, 6 Sep 2018 10:45:01 +0200 Subject: Adapting local docs build and remove build warnings The OPNFV docs project will remove its submodules and enable local docs builds. This patch prepares the Dovetail repo according to the official transition guide: https://docs.opnfv.org/en/latest/how-to-use-docs/local-build-transition.html This patch also applies syntactical changes which eliminate the sphinx doc build warnings. Change-Id: Ief8fd2d1c3e39b232d214a9ab392879ee4a492c8 Signed-off-by: Georg Kunz (cherry picked from commit a18e2b0d45c631709e457530f6f9d0b52f552156) --- .../exemption-strict-API-validation.rst | 2 +- docs/testing/user/reviewerguide/index.rst | 2 +- docs/testing/user/systempreparation/index.rst | 2 +- .../testspecification/highavailability/index.rst | 7 +- docs/testing/user/testspecification/index.rst | 42 +-- .../user/testspecification/stress/index.rst | 4 +- .../tempest_identity_v3/index.rst | 6 +- .../testspecification/tempest_ipv6/ipv6_api.rst | 8 +- .../tempest_network/network_scenario.rst | 417 --------------------- .../tempest_network_scenario/index.rst | 417 +++++++++++++++++++++ .../tempest_trunk_ports/index.rst | 4 +- docs/testing/user/userguide/cli_reference.rst | 2 +- 12 files changed, 458 insertions(+), 455 deletions(-) delete mode 100644 docs/testing/user/testspecification/tempest_network/network_scenario.rst create mode 100644 docs/testing/user/testspecification/tempest_network_scenario/index.rst (limited to 'docs/testing') diff --git a/docs/testing/user/ovpaddendum/exemption-strict-API-validation.rst b/docs/testing/user/ovpaddendum/exemption-strict-API-validation.rst index b4466111..aaac6c4c 100644 --- a/docs/testing/user/ovpaddendum/exemption-strict-API-validation.rst +++ b/docs/testing/user/ovpaddendum/exemption-strict-API-validation.rst @@ -89,7 +89,7 @@ Example: additional attributes per VM for HA policy --------------------------------------------------- This fictional example showcases the presence of an additional attribute in an -API response. The example shows that the 'server details', i.e. the VM +API response. The example shows that the 'server details' [3]_, i.e. the VM metadata, includes an additional attribute 'ha-policy' which is used to associate high-availability policies with a VM instance. This attribute is utilized by a proprietary add-on component to manage VM migration and recovery diff --git a/docs/testing/user/reviewerguide/index.rst b/docs/testing/user/reviewerguide/index.rst index 25dc2f68..dd9456ce 100644 --- a/docs/testing/user/reviewerguide/index.rst +++ b/docs/testing/user/reviewerguide/index.rst @@ -155,7 +155,7 @@ The bottlenecks log must contain the 'SUCCESS' result as shown in following exam Functest logs opens an html page that lists all test cases as shown in figure 7. All test cases must have run successfuly. -.. image:: images/ovp_log_functest_image.png +.. image:: images/ovp_log_files_functest_image.png :align: center :scale: 100% diff --git a/docs/testing/user/systempreparation/index.rst b/docs/testing/user/systempreparation/index.rst index 4e101146..5bc150a3 100644 --- a/docs/testing/user/systempreparation/index.rst +++ b/docs/testing/user/systempreparation/index.rst @@ -52,7 +52,7 @@ The SUT is expected to be connected with high performance networks. These networ are expected in the SUT: - A management network by which the Test Node can reach all identity, image, network, -and compute services in the SUT + and compute services in the SUT - A data network that supports the virtual network capabilities and data path testing Additional networks, such as Light Out Management or storage networks, may be diff --git a/docs/testing/user/testspecification/highavailability/index.rst b/docs/testing/user/testspecification/highavailability/index.rst index e024b1fc..dd98ba94 100644 --- a/docs/testing/user/testspecification/highavailability/index.rst +++ b/docs/testing/user/testspecification/highavailability/index.rst @@ -810,9 +810,10 @@ For second monitor is used a process monitor and the main purpose is to watch whether the database processes on the host node are killed properly. Therefore, in this test case, there are two metrics: -- service_outage_time, which indicates the maximum outage time (seconds) + +* service_outage_time, which indicates the maximum outage time (seconds) of the specified OpenStack command request -- process_recover_time, which indicates the maximum time (seconds) from the +* process_recover_time, which indicates the maximum time (seconds) from the process being killed to recovered Test execution @@ -1056,7 +1057,7 @@ Process recovery is verified by checking the existence of processes of Test execution '''''''''''''' * Test action 1: Two host VMs are booted, these two hosts are in two different -networks, the networks are connected by a virtual router. + networks, the networks are connected by a virtual router. * Test action 2: Start monitors: each monitor will run with independently process. The monitor info will be collected. * Test action 3: Do attacker: Connect the host through SSH, and then execute the kill diff --git a/docs/testing/user/testspecification/index.rst b/docs/testing/user/testspecification/index.rst index fff07ee9..9fff4689 100644 --- a/docs/testing/user/testspecification/index.rst +++ b/docs/testing/user/testspecification/index.rst @@ -25,24 +25,24 @@ All tests areas addressed in the OVP are covered in the following test specification documents. .. toctree:: - :maxdepth: 1 - - ./highavailability/index.rst - ./tempest_osinterop/index.rst - ./vping/index.rst - ./tempest_trunk_ports/index.rst - ./security_patrole/index.rst - ./tempest_ipv6/index.rst - ./tempest_network_security/index.rst - ./tempest_network/network_scenario.rst - ./tempest_vm_lifecycle/index.rst - ./tempest_multi_node_scheduling/index.rst - ./vpn/index.rst - ./vnf/index.rst - ./stress/index.rst - ./snaps_smoke/index.rst - ./tempest_compute/index.rst - ./tempest_identity_v3/index.rst - ./tempest_image/index.rst - ./tempest_network/index.rst - ./tempest_volume/index.rst \ No newline at end of file + :maxdepth: 2 + + highavailability/index + security_patrole/index + snaps_smoke/index + stress/index + tempest_compute/index + tempest_identity_v3/index + tempest_image/index + tempest_ipv6/index + tempest_multi_node_scheduling/index + tempest_network_api/index + tempest_network_scenario/index + tempest_network_security/index + tempest_osinterop/index + tempest_trunk_ports/index + tempest_vm_lifecycle/index + tempest_volume/index + vnf/index + vping/index + vpn/index diff --git a/docs/testing/user/testspecification/stress/index.rst b/docs/testing/user/testspecification/stress/index.rst index 41c84e7c..74961fd1 100644 --- a/docs/testing/user/testspecification/stress/index.rst +++ b/docs/testing/user/testspecification/stress/index.rst @@ -18,7 +18,7 @@ the SUT is able to absorb failures while providing an acceptable level of servic References -================ +========== This test area references the following specifications, definitions and reviews: @@ -96,7 +96,7 @@ Basic test flow execution description and pass/fail criteria ------------------------------------------------------------ Methodology for validating capacity of the SUT -''''''''''''''''''''''''''''''''''''''''''''' +'''''''''''''''''''''''''''''''''''''''''''''' Validating capacity of the SUT based on life-cycle ping test generally involves 2 subtests which provides secondary validation for the SUT furnishing users with reliable capacity without being crushed. diff --git a/docs/testing/user/testspecification/tempest_identity_v3/index.rst b/docs/testing/user/testspecification/tempest_identity_v3/index.rst index e5e8f901..bb60b204 100644 --- a/docs/testing/user/testspecification/tempest_identity_v3/index.rst +++ b/docs/testing/user/testspecification/tempest_identity_v3/index.rst @@ -31,7 +31,7 @@ These runtime operations may include that create, list, verify and delete: References ========== -`Identity API v3.0 `_ System Under Test (SUT) ======================= @@ -52,7 +52,7 @@ OVP test suite. - `Create, Get, Update and Delete Credentials `_ - tempest.api.identity.admin.v3.test_credentials.CredentialsTestJSON.test_credentials_create_get_update_delete -- `Create and Verify Domain `_ +- `Create and Verify Domain `_ - tempest.api.identity.admin.v3.test_domains.DefaultDomainTestJSON.test_default_domain_exists - `Create, Update and Delete Domain `_ @@ -80,4 +80,4 @@ OVP test suite. - tempest.api.identity.admin.v3.test_trusts.TrustsV3TestJSON.test_get_trusts_all - `List API Versions `_ - - tempest.api.identity.v3.test_api_discovery.TestApiDiscovery.test_list_api_versions \ No newline at end of file + - tempest.api.identity.v3.test_api_discovery.TestApiDiscovery.test_list_api_versions diff --git a/docs/testing/user/testspecification/tempest_ipv6/ipv6_api.rst b/docs/testing/user/testspecification/tempest_ipv6/ipv6_api.rst index 79005329..60a5633e 100644 --- a/docs/testing/user/testspecification/tempest_ipv6/ipv6_api.rst +++ b/docs/testing/user/testspecification/tempest_ipv6/ipv6_api.rst @@ -161,10 +161,12 @@ Test preconditions ------------------ 1. The SUT has at least one external network. -2. In the external network list, there is no network without external router, i.e., -all networks in this list are with external router. + +2. In the external network list, there is no network without external router, + i.e., all networks in this list are with external router. + 3. There is one external network with configured public network id and there is -no subnet on this network + no subnet on this network Basic test flow execution description and pass/fail criteria ------------------------------------------------------------ diff --git a/docs/testing/user/testspecification/tempest_network/network_scenario.rst b/docs/testing/user/testspecification/tempest_network/network_scenario.rst deleted file mode 100644 index 6c172474..00000000 --- a/docs/testing/user/testspecification/tempest_network/network_scenario.rst +++ /dev/null @@ -1,417 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) Huawei Technologies Co.,Ltd - -=========================================== -Tempest Network Scenario test specification -=========================================== - -.. toctree:: - :maxdepth: 2 - -Scope -===== - -The Tempest Network scenario test area evaluates the ability of the -system under test to support dynamic network runtime operations through the -life of a VNF (e.g. attach/detach, enable/disable, read stats). -The tests in this test area will evaluate IPv4 network runtime operations -functionality. These runtime operations includes hotpluging network interface, -detaching floating-ip from VM, attaching floating-ip to VM, updating subnet's -DNS, updating VM instance port admin state and updating router admin state. - -References -========== - -- DNS - - - https://docs.openstack.org/newton/networking-guide/config-dns-res.html - -Definitions and abbreviations -============================= - -The following terms and abbreviations are used in conjunction with this test -area - -- API - Application Programming Interface -- DNS - Domain Name System -- ICMP - Internet Control Message Protocol -- MAC - Media Access Control -- NIC - Network Interface Controller -- NFVi - Network Functions Virtualization infrastructure -- SSH - Secure Shell -- TCP - Transmission Control Protocol -- VIM - Virtual Infrastructure Manager -- 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 based on dynamic network runtime operations. Each -test case is able to run independently, i.e. irrelevant of the state created by -a previous test. Specifically, every test performs clean-up operations which -return the system to the same state as before the test. - -All these test cases are included in the test case dovetail.tempest.network_scenario of -OVP test suite. - -Test Descriptions -================= - ----------------------- -API Used and Reference ----------------------- - -Security Groups: https://developer.openstack.org/api-ref/network/v2/index.html#security-groups-security-groups - -- create security group -- delete security group - -Networks: https://developer.openstack.org/api-ref/networking/v2/index.html#networks - -- create network -- delete network - -Routers and interface: https://developer.openstack.org/api-ref/networking/v2/index.html#routers-routers - -- create router -- update router -- delete router -- add interface to router - -Subnets: https://developer.openstack.org/api-ref/networking/v2/index.html#subnets - -- create subnet -- update subnet -- delete subnet - -Servers: https://developer.openstack.org/api-ref/compute/ - -- create keypair -- create server -- delete server -- add/assign floating IP -- disassociate floating IP - -Ports: https://developer.openstack.org/api-ref/networking/v2/index.html#ports - -- create port -- update port -- delete port - -Floating IPs: https://developer.openstack.org/api-ref/networking/v2/index.html#floating-ips-floatingips - -- create floating IP -- delete floating IP - --------------------------------------- -Test Case 1 - Basic network operations --------------------------------------- - -Test case specification ------------------------ - -tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops - -Test preconditions ------------------- - -* Nova has been configured to boot VMs with Neutron-managed networking -* Openstack nova, neutron services are available -* One public network - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -'''''''''''''' - -* Test action 1: Create a security group SG1, which has rules for allowing - incoming SSH and ICMP traffic -* Test action 2: Create a neutron network NET1 -* Test action 3: Create a tenant router R1 which routes traffic to public network -* Test action 4: Create a subnet SUBNET1 and add it as router interface -* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating - IP FIP1 (via R1) to VM1 -* **Test assertion 1:** Ping FIP1 and SSH to VM1 via FIP1 successfully -* **Test assertion 2:** Ping the internal gateway from VM1 successfully -* **Test assertion 3:** Ping the default gateway from VM1 using its floating IP - FIP1 successfully -* Test action 6: Detach FIP1 from VM1 -* **Test assertion 4:** VM1 becomes unreachable after FIP1 disassociated -* Test action 7: Create a new server VM2 with NET1, and associate floating IP FIP1 to VM2 -* **Test assertion 5:** Ping FIP1 and SSH to VM2 via FIP1 successfully -* Test action 8: Delete SG1, NET1, SUBNET1, R1, VM1, VM2 and FIP1 - -Pass / fail criteria -'''''''''''''''''''' - -This test evaluates the functionality of basic network operations. -Specifically, the test verifies that: - -* The Tempest host can ping VM's IP address. This implies, but does not - guarantee (see the ssh check that follows), that the VM has been assigned the - correct IP address and has connectivity to the Tempest host. - -* The Tempest host can perform key-based authentication to an ssh server hosted - at VM's IP address. This check guarantees that the IP address is associated - with the target VM. - -* The Tempest host can ssh into the VM via the IP address and successfully ping - the internal gateway address, implying connectivity to another VM on the same network. - -* The Tempest host can ssh into the VM via the IP address and successfully ping - the default gateway, implying external connectivity. - -* Detach the floating-ip from the VM and VM becomes unreachable. - -* Associate attached floating ip to a new VM and the new VM is reachable. - -* Floating IP status is updated correctly after each change. - -In order to pass this test, all test assertions listed in the test execution above need to pass. - -Post conditions ---------------- - -N/A - ---------------------------------------- -Test Case 2 - Hotplug network interface ---------------------------------------- - -Test case specification ------------------------ - -tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic - -Test preconditions ------------------- - -* Nova has been configured to boot VMs with Neutron-managed networking -* Compute interface_attach feature is enabled -* VM vnic_type is not set to 'direct' or 'macvtap' -* Openstack nova, neutron services are available -* One public network - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -'''''''''''''' - -* Test action 1: Create a security group SG1, which has rules for allowing - incoming SSH and ICMP traffic -* Test action 2: Create a neutron network NET1 -* Test action 3: Create a tenant router R1 which routes traffic to public network -* Test action 4: Create a subnet SUBNET1 and add it as router interface -* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating - IP FIP1 (via R1) to VM1 -* **Test assertion 1:** Ping FIP1 and SSH to VM1 with FIP1 successfully -* Test action 6: Create a second neutron network NET2 and subnet SUBNET2, and - attach VM1 to NET2 -* Test action 7: Get VM1's ethernet interface NIC2 for NET2 -* **Test assertion 2:** Ping NET2's internal gateway successfully -* Test action 8: Delete SG1, NET1, NET2, SUBNET1, SUBNET2, R1, NIC2, VM1 and FIP1 - -Pass / fail criteria -'''''''''''''''''''' - -This test evaluates the functionality of adding network to an active VM. -Specifically, the test verifies that: - -* New network interface can be added to an existing VM successfully. - -* The Tempest host can ssh into the VM via the IP address and successfully ping - the new network's internal gateway address, implying connectivity to the new network. - -In order to pass this test, all test assertions listed in the test execution above need to pass. - -Post conditions ---------------- - -N/A - -------------------------------------------- -Test Case 3 - Update subnet's configuration -------------------------------------------- - -Test case specification ------------------------ - -tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_subnet_details - -Test preconditions ------------------- - -* Nova has been configured to boot VMs with Neutron-managed networking -* DHCP client is available -* Tenant networks should be non-shared and isolated -* Openstack nova, neutron services are available -* One public network - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -'''''''''''''' - -* Test action 1: Create a security group SG1, which has rules for allowing - incoming SSH and ICMP traffic -* Test action 2: Create a neutron network NET1 -* Test action 3: Create a tenant router R1 which routes traffic to public network -* Test action 4: Create a subnet SUBNET1 and add it as router interface, - configure SUBNET1 with dns nameserver '1.2.3.4' -* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating - IP FIP1 (via R1) to VM1 -* **Test assertion 1:** Ping FIP1 and SSH to VM1 with FIP1 successfully -* **Test assertion 2:** Retrieve the VM1's configured dns and verify it matches - the one configured for SUBNET1 -* Test action 6: Update SUBNET1's dns to '9.8.7.6' -* **Test assertion 3:** After triggering the DHCP renew from the VM manually, - retrieve the VM1's configured dns and verify it has been successfully updated -* Test action 7: Delete SG1, NET1, SUBNET1, R1, VM1 and FIP1 - -Pass / fail criteria -'''''''''''''''''''' - -This test evaluates the functionality of updating subnet's configurations. -Specifically, the test verifies that: - -* Updating subnet's DNS server configurations are affecting the VMs. - -In order to pass this test, all test assertions listed in the test execution above need to pass. - -Post conditions ---------------- - -N/A - ----------------------------------------- -Test Case 4 - Update VM port admin state ----------------------------------------- - -Test case specification ------------------------ - -tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_update_instance_port_admin_state - -Test preconditions ------------------- - -* Nova has been configured to boot VMs with Neutron-managed networking -* Network port_admin_state_change feature is enabled -* Openstack nova, neutron services are available -* One public network - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -'''''''''''''' - -* Test action 1: Create a security group SG1, which has rules for allowing - incoming SSH and ICMP traffic -* Test action 2: Create a neutron network NET1 -* Test action 3: Create a tenant router R1 which routes traffic to public network -* Test action 4: Create a subnet SUBNET1 and add it as router interface -* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating - IP FIP1 (via R1) to VM1 -* Test action 6: Create a server VM2 with SG1 and NET1, and assign a floating - IP FIP2 to VM2 -* Test action 7: Get a SSH client SSHCLNT1 to VM2 -* **Test assertion 1:** Ping FIP1 and SSH to VM1 with FIP1 successfully -* **Test assertion 2:** Ping FIP1 via SSHCLNT1 successfully -* Test action 8: Update admin_state_up attribute of VM1 port to False -* **Test assertion 3:** Ping FIP1 and SSH to VM1 with FIP1 failed -* **Test assertion 4:** Ping FIP1 via SSHCLNT1 failed -* Test action 9: Update admin_state_up attribute of VM1 port to True -* **Test assertion 5:** Ping FIP1 and SSH to VM1 with FIP1 successfully -* **Test assertion 6:** Ping FIP1 via SSHCLNT1 successfully -* Test action 10: Delete SG1, NET1, SUBNET1, R1, SSHCLNT1, VM1, VM2 and FIP1, FIP2 - -Pass / fail criteria -'''''''''''''''''''' - -This test evaluates the VM public and project connectivity status by changing VM port -admin_state_up to True & False. Specifically, the test verifies that: - -* Public and project connectivity is reachable before updating admin_state_up - attribute of VM port to False. - -* Public and project connectivity is unreachable after updating admin_state_up - attribute of VM port to False. - -* Public and project connectivity is reachable after updating admin_state_up - attribute of VM port from False to True. - -In order to pass this test, all test assertions listed in the test execution above need to pass. - -Post conditions ---------------- - -N/A - ---------------------------------------- -Test Case 5 - Update router admin state ---------------------------------------- - -Test case specification ------------------------ - -tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_update_router_admin_state - -Test preconditions ------------------- - -* Nova has been configured to boot VMs with Neutron-managed networking -* Multi-tenant networks capabilities -* Openstack nova, neutron services are available -* One public network - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -'''''''''''''' - -* Test action 1: Create a security group SG1, which has rules for allowing - incoming SSH and ICMP traffic -* Test action 2: Create a neutron network NET1 -* Test action 3: Create a tenant router R1 which routes traffic to public network -* Test action 4: Create a subnet SUBNET1 and add it as router interface -* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating - IP FIP1 (via R1) to VM1 -* **Test assertion 1:** Ping FIP1 and SSH to VM1 with FIP1 successfully -* Test action 6: Update admin_state_up attribute of R1 to False -* **Test assertion 2:** Ping FIP1 and SSH to VM1 with FIP1 failed -* Test action 7: Update admin_state_up attribute of R1 to True -* **Test assertion 3:** Ping FIP1 and SSH to VM1 with FIP1 successfully -* Test action 8: Delete SG1, NET1, SUBNET1, R1, VM1 and FIP1 - -Pass / fail criteria -'''''''''''''''''''' - -This test evaluates the router public connectivity status by changing -router admin_state_up to True & False. -Specifically, the test verifies that: - -* Public connectivity is reachable before updating admin_state_up attribute of router to False. - -* Public connectivity is unreachable after updating admin_state_up attribute of router to False. - -* Public connectivity is reachable after updating admin_state_up attribute of router. - from False to True - -In order to pass this test, all test assertions listed in the test execution above need to pass. - -Post conditions ---------------- - -N/A diff --git a/docs/testing/user/testspecification/tempest_network_scenario/index.rst b/docs/testing/user/testspecification/tempest_network_scenario/index.rst new file mode 100644 index 00000000..6c172474 --- /dev/null +++ b/docs/testing/user/testspecification/tempest_network_scenario/index.rst @@ -0,0 +1,417 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Huawei Technologies Co.,Ltd + +=========================================== +Tempest Network Scenario test specification +=========================================== + +.. toctree:: + :maxdepth: 2 + +Scope +===== + +The Tempest Network scenario test area evaluates the ability of the +system under test to support dynamic network runtime operations through the +life of a VNF (e.g. attach/detach, enable/disable, read stats). +The tests in this test area will evaluate IPv4 network runtime operations +functionality. These runtime operations includes hotpluging network interface, +detaching floating-ip from VM, attaching floating-ip to VM, updating subnet's +DNS, updating VM instance port admin state and updating router admin state. + +References +========== + +- DNS + + - https://docs.openstack.org/newton/networking-guide/config-dns-res.html + +Definitions and abbreviations +============================= + +The following terms and abbreviations are used in conjunction with this test +area + +- API - Application Programming Interface +- DNS - Domain Name System +- ICMP - Internet Control Message Protocol +- MAC - Media Access Control +- NIC - Network Interface Controller +- NFVi - Network Functions Virtualization infrastructure +- SSH - Secure Shell +- TCP - Transmission Control Protocol +- VIM - Virtual Infrastructure Manager +- 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 based on dynamic network runtime operations. Each +test case is able to run independently, i.e. irrelevant of the state created by +a previous test. Specifically, every test performs clean-up operations which +return the system to the same state as before the test. + +All these test cases are included in the test case dovetail.tempest.network_scenario of +OVP test suite. + +Test Descriptions +================= + +---------------------- +API Used and Reference +---------------------- + +Security Groups: https://developer.openstack.org/api-ref/network/v2/index.html#security-groups-security-groups + +- create security group +- delete security group + +Networks: https://developer.openstack.org/api-ref/networking/v2/index.html#networks + +- create network +- delete network + +Routers and interface: https://developer.openstack.org/api-ref/networking/v2/index.html#routers-routers + +- create router +- update router +- delete router +- add interface to router + +Subnets: https://developer.openstack.org/api-ref/networking/v2/index.html#subnets + +- create subnet +- update subnet +- delete subnet + +Servers: https://developer.openstack.org/api-ref/compute/ + +- create keypair +- create server +- delete server +- add/assign floating IP +- disassociate floating IP + +Ports: https://developer.openstack.org/api-ref/networking/v2/index.html#ports + +- create port +- update port +- delete port + +Floating IPs: https://developer.openstack.org/api-ref/networking/v2/index.html#floating-ips-floatingips + +- create floating IP +- delete floating IP + +-------------------------------------- +Test Case 1 - Basic network operations +-------------------------------------- + +Test case specification +----------------------- + +tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops + +Test preconditions +------------------ + +* Nova has been configured to boot VMs with Neutron-managed networking +* Openstack nova, neutron services are available +* One public network + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +'''''''''''''' + +* Test action 1: Create a security group SG1, which has rules for allowing + incoming SSH and ICMP traffic +* Test action 2: Create a neutron network NET1 +* Test action 3: Create a tenant router R1 which routes traffic to public network +* Test action 4: Create a subnet SUBNET1 and add it as router interface +* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating + IP FIP1 (via R1) to VM1 +* **Test assertion 1:** Ping FIP1 and SSH to VM1 via FIP1 successfully +* **Test assertion 2:** Ping the internal gateway from VM1 successfully +* **Test assertion 3:** Ping the default gateway from VM1 using its floating IP + FIP1 successfully +* Test action 6: Detach FIP1 from VM1 +* **Test assertion 4:** VM1 becomes unreachable after FIP1 disassociated +* Test action 7: Create a new server VM2 with NET1, and associate floating IP FIP1 to VM2 +* **Test assertion 5:** Ping FIP1 and SSH to VM2 via FIP1 successfully +* Test action 8: Delete SG1, NET1, SUBNET1, R1, VM1, VM2 and FIP1 + +Pass / fail criteria +'''''''''''''''''''' + +This test evaluates the functionality of basic network operations. +Specifically, the test verifies that: + +* The Tempest host can ping VM's IP address. This implies, but does not + guarantee (see the ssh check that follows), that the VM has been assigned the + correct IP address and has connectivity to the Tempest host. + +* The Tempest host can perform key-based authentication to an ssh server hosted + at VM's IP address. This check guarantees that the IP address is associated + with the target VM. + +* The Tempest host can ssh into the VM via the IP address and successfully ping + the internal gateway address, implying connectivity to another VM on the same network. + +* The Tempest host can ssh into the VM via the IP address and successfully ping + the default gateway, implying external connectivity. + +* Detach the floating-ip from the VM and VM becomes unreachable. + +* Associate attached floating ip to a new VM and the new VM is reachable. + +* Floating IP status is updated correctly after each change. + +In order to pass this test, all test assertions listed in the test execution above need to pass. + +Post conditions +--------------- + +N/A + +--------------------------------------- +Test Case 2 - Hotplug network interface +--------------------------------------- + +Test case specification +----------------------- + +tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic + +Test preconditions +------------------ + +* Nova has been configured to boot VMs with Neutron-managed networking +* Compute interface_attach feature is enabled +* VM vnic_type is not set to 'direct' or 'macvtap' +* Openstack nova, neutron services are available +* One public network + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +'''''''''''''' + +* Test action 1: Create a security group SG1, which has rules for allowing + incoming SSH and ICMP traffic +* Test action 2: Create a neutron network NET1 +* Test action 3: Create a tenant router R1 which routes traffic to public network +* Test action 4: Create a subnet SUBNET1 and add it as router interface +* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating + IP FIP1 (via R1) to VM1 +* **Test assertion 1:** Ping FIP1 and SSH to VM1 with FIP1 successfully +* Test action 6: Create a second neutron network NET2 and subnet SUBNET2, and + attach VM1 to NET2 +* Test action 7: Get VM1's ethernet interface NIC2 for NET2 +* **Test assertion 2:** Ping NET2's internal gateway successfully +* Test action 8: Delete SG1, NET1, NET2, SUBNET1, SUBNET2, R1, NIC2, VM1 and FIP1 + +Pass / fail criteria +'''''''''''''''''''' + +This test evaluates the functionality of adding network to an active VM. +Specifically, the test verifies that: + +* New network interface can be added to an existing VM successfully. + +* The Tempest host can ssh into the VM via the IP address and successfully ping + the new network's internal gateway address, implying connectivity to the new network. + +In order to pass this test, all test assertions listed in the test execution above need to pass. + +Post conditions +--------------- + +N/A + +------------------------------------------- +Test Case 3 - Update subnet's configuration +------------------------------------------- + +Test case specification +----------------------- + +tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_subnet_details + +Test preconditions +------------------ + +* Nova has been configured to boot VMs with Neutron-managed networking +* DHCP client is available +* Tenant networks should be non-shared and isolated +* Openstack nova, neutron services are available +* One public network + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +'''''''''''''' + +* Test action 1: Create a security group SG1, which has rules for allowing + incoming SSH and ICMP traffic +* Test action 2: Create a neutron network NET1 +* Test action 3: Create a tenant router R1 which routes traffic to public network +* Test action 4: Create a subnet SUBNET1 and add it as router interface, + configure SUBNET1 with dns nameserver '1.2.3.4' +* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating + IP FIP1 (via R1) to VM1 +* **Test assertion 1:** Ping FIP1 and SSH to VM1 with FIP1 successfully +* **Test assertion 2:** Retrieve the VM1's configured dns and verify it matches + the one configured for SUBNET1 +* Test action 6: Update SUBNET1's dns to '9.8.7.6' +* **Test assertion 3:** After triggering the DHCP renew from the VM manually, + retrieve the VM1's configured dns and verify it has been successfully updated +* Test action 7: Delete SG1, NET1, SUBNET1, R1, VM1 and FIP1 + +Pass / fail criteria +'''''''''''''''''''' + +This test evaluates the functionality of updating subnet's configurations. +Specifically, the test verifies that: + +* Updating subnet's DNS server configurations are affecting the VMs. + +In order to pass this test, all test assertions listed in the test execution above need to pass. + +Post conditions +--------------- + +N/A + +---------------------------------------- +Test Case 4 - Update VM port admin state +---------------------------------------- + +Test case specification +----------------------- + +tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_update_instance_port_admin_state + +Test preconditions +------------------ + +* Nova has been configured to boot VMs with Neutron-managed networking +* Network port_admin_state_change feature is enabled +* Openstack nova, neutron services are available +* One public network + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +'''''''''''''' + +* Test action 1: Create a security group SG1, which has rules for allowing + incoming SSH and ICMP traffic +* Test action 2: Create a neutron network NET1 +* Test action 3: Create a tenant router R1 which routes traffic to public network +* Test action 4: Create a subnet SUBNET1 and add it as router interface +* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating + IP FIP1 (via R1) to VM1 +* Test action 6: Create a server VM2 with SG1 and NET1, and assign a floating + IP FIP2 to VM2 +* Test action 7: Get a SSH client SSHCLNT1 to VM2 +* **Test assertion 1:** Ping FIP1 and SSH to VM1 with FIP1 successfully +* **Test assertion 2:** Ping FIP1 via SSHCLNT1 successfully +* Test action 8: Update admin_state_up attribute of VM1 port to False +* **Test assertion 3:** Ping FIP1 and SSH to VM1 with FIP1 failed +* **Test assertion 4:** Ping FIP1 via SSHCLNT1 failed +* Test action 9: Update admin_state_up attribute of VM1 port to True +* **Test assertion 5:** Ping FIP1 and SSH to VM1 with FIP1 successfully +* **Test assertion 6:** Ping FIP1 via SSHCLNT1 successfully +* Test action 10: Delete SG1, NET1, SUBNET1, R1, SSHCLNT1, VM1, VM2 and FIP1, FIP2 + +Pass / fail criteria +'''''''''''''''''''' + +This test evaluates the VM public and project connectivity status by changing VM port +admin_state_up to True & False. Specifically, the test verifies that: + +* Public and project connectivity is reachable before updating admin_state_up + attribute of VM port to False. + +* Public and project connectivity is unreachable after updating admin_state_up + attribute of VM port to False. + +* Public and project connectivity is reachable after updating admin_state_up + attribute of VM port from False to True. + +In order to pass this test, all test assertions listed in the test execution above need to pass. + +Post conditions +--------------- + +N/A + +--------------------------------------- +Test Case 5 - Update router admin state +--------------------------------------- + +Test case specification +----------------------- + +tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_update_router_admin_state + +Test preconditions +------------------ + +* Nova has been configured to boot VMs with Neutron-managed networking +* Multi-tenant networks capabilities +* Openstack nova, neutron services are available +* One public network + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +'''''''''''''' + +* Test action 1: Create a security group SG1, which has rules for allowing + incoming SSH and ICMP traffic +* Test action 2: Create a neutron network NET1 +* Test action 3: Create a tenant router R1 which routes traffic to public network +* Test action 4: Create a subnet SUBNET1 and add it as router interface +* Test action 5: Create a server VM1 with SG1 and NET1, and assign a floating + IP FIP1 (via R1) to VM1 +* **Test assertion 1:** Ping FIP1 and SSH to VM1 with FIP1 successfully +* Test action 6: Update admin_state_up attribute of R1 to False +* **Test assertion 2:** Ping FIP1 and SSH to VM1 with FIP1 failed +* Test action 7: Update admin_state_up attribute of R1 to True +* **Test assertion 3:** Ping FIP1 and SSH to VM1 with FIP1 successfully +* Test action 8: Delete SG1, NET1, SUBNET1, R1, VM1 and FIP1 + +Pass / fail criteria +'''''''''''''''''''' + +This test evaluates the router public connectivity status by changing +router admin_state_up to True & False. +Specifically, the test verifies that: + +* Public connectivity is reachable before updating admin_state_up attribute of router to False. + +* Public connectivity is unreachable after updating admin_state_up attribute of router to False. + +* Public connectivity is reachable after updating admin_state_up attribute of router. + from False to True + +In order to pass this test, all test assertions listed in the test execution above need to pass. + +Post conditions +--------------- + +N/A diff --git a/docs/testing/user/testspecification/tempest_trunk_ports/index.rst b/docs/testing/user/testspecification/tempest_trunk_ports/index.rst index 0507cd9a..fd60a32e 100644 --- a/docs/testing/user/testspecification/tempest_trunk_ports/index.rst +++ b/docs/testing/user/testspecification/tempest_trunk_ports/index.rst @@ -36,7 +36,7 @@ test. For detailed information on the individual steps and assertions performed by the tests, review the Python source code accessible via the following links: - `Neutron Trunk API tests `_ -- `Neutron Trunk API negative tests `_ +- `Neutron Trunk API trunk details `_ - `Neutron Trunk API negative tests `_ @@ -117,7 +117,7 @@ These group of tests comprise negative tests which verify that invalid operation are handled correctly by the system under test. Implementation: -`TrunkTestJSON `_ +`TrunkTestNegative `_ - neutron.tests.tempest.api.test_trunk_negative.TrunkTestJSON.test_add_subport_duplicate_segmentation_details - neutron.tests.tempest.api.test_trunk_negative.TrunkTestJSON.test_add_subport_passing_dict diff --git a/docs/testing/user/userguide/cli_reference.rst b/docs/testing/user/userguide/cli_reference.rst index 891617aa..97eccffc 100644 --- a/docs/testing/user/userguide/cli_reference.rst +++ b/docs/testing/user/userguide/cli_reference.rst @@ -72,7 +72,7 @@ Commands List | dovetail run --optional --testsuite | Run Dovetail with all optional test cases within test suite | | | | +------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------+ -| dovetail run --debug | -d | Run Dovetail with debug mode and show all debug logs | +| dovetail run --debug | -d | Run Dovetail with debug mode and show all debug logs | | | | +------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------+ | dovetail run --offline | Run Dovetail offline, use local docker images instead of download online | -- cgit 1.2.3-korg