diff options
| author |   xudan <xudan16@huawei.com> | 2018-07-04 02:41:09 -0400 |
|---|---|---|
| committer |   Georg Kunz <georg.kunz@ericsson.com> | 2018-07-04 11:25:44 +0000 |
| commit | 12aba80ab0cae835cf077c9592129070b401cf59 (patch) | |
| tree | 9ba596a06c0b0e01dc14418f6f938e1cf4de4bf4 | |
| parent | 22f1f4b049736f1fa24ec3f5b7d1248c93bbb6ea (diff) | |
Update all existing test specifications
1. Update the names of 2 vping test cases
2. Update the names of 8 ha test cases
3. Update the sub test cases within osinterop 2017.09
4. Split IPv6 into ipv6_api and ipv6_scenario
5. Update the names of sdnvpn test cases
6. Update the names of 4 tempest scenario test cases
7. Remove forwardingpackets
JIRA: DOVETAIL-685
Change-Id: I0d91b8a0477576e18581eb2788fdb666063c89b7
Signed-off-by: xudan <xudan16@huawei.com>
19 files changed, 1224 insertions, 1287 deletions
diff --git a/docs/testing/user/testspecification/faultmanagement/index.rst b/docs/testing/user/testspecification/faultmanagement/index.rst deleted file mode 100644 index e69de29b..00000000 --- a/docs/testing/user/testspecification/faultmanagement/index.rst +++ /dev/null diff --git a/docs/testing/user/testspecification/forwardingpackets/index.rst b/docs/testing/user/testspecification/forwardingpackets/index.rst deleted file mode 100644 index 4a4ffea9..00000000 --- a/docs/testing/user/testspecification/forwardingpackets/index.rst +++ /dev/null @@ -1,147 +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 - -================================================== -Forwarding Packets in Data Path test specification -================================================== - -.. toctree:: - :maxdepth: 2 - -Scope -===== - -This test area evaluates the ability of the system under test to support basic packet forwarding. -The test in this test area will evaluate basic packet forwarding through virtual IPv4 networks -in data path, including creating server and verifying network connectivity to the created server -with ping operation using MTU sized packets. - -References -========== - -N/A - -Definitions and abbreviations -============================= - -The following terms and abbreviations are used in conjunction with this test -area - -- API - Application Programming Interface -- ICMP - Internet Control Message Protocol -- MTU - Maximum Transmission Unit -- NFVi - Network Functions Virtualization infrastructure -- SSH - Secure Shell -- 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 the basic operations of forwarding packets -in data path through virtual networks. Specifically, the test performs -clean-up operations which return the system to the same state as before the test. - -This test case is included in the test case dovetail.tempest.tc001 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 -- delete router -- add interface to router - -Subnets: https://developer.openstack.org/api-ref/networking/v2/index.html#subnets - -- create subnet -- delete subnet - -Servers: https://developer.openstack.org/api-ref/compute/ - -- create keypair -- create server -- delete server -- add/assign floating ip - -Ports: https://developer.openstack.org/api-ref/networking/v2/index.html#ports - -- create port -- delete port - -Floating IPs: https://developer.openstack.org/api-ref/networking/v2/index.html#floating-ips-floatingips - -- create floating ip -- delete floating ip - ----------------------------- -MTU Sized Frames Fit Through ----------------------------- - -Test case specification ------------------------ - -tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_mtu_sized_frames - -Test preconditions ------------------- - -* Nova has been configured to boot VMs with Neutron-managed networking -* Neutron net-mtu extension API -* 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 and outgoing 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: Set MTU size to be the default MTU size of the SUT's network -* Test action 7: Host sends MTU sized ICMP packets to VM1 using ``ping`` -* **Test assertion 1:** Ping FIP1 using MTU sized packets successfully -* Test action 8: SSH to VM1 with FIP1 -* **Test assertion 2:** SSH to VM1 with FIP1 successfully -* Test action 9: Delete SG1, NET1, SUBNET1, R1, VM1 and FIP1 - -Pass / fail criteria -'''''''''''''''''''' - -This test evaluates the network connectivity using MTU sized frames. -Specifically, the test verifies that: - -* With Neutron net-mtu extension configured, MTU sized packets can fit through network. - -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/highavailability/index.rst b/docs/testing/user/testspecification/highavailability/index.rst index 1dd99d41..280a241e 100644 --- a/docs/testing/user/testspecification/highavailability/index.rst +++ b/docs/testing/user/testspecification/highavailability/index.rst @@ -84,7 +84,7 @@ Test Case 1 - Controller node OpenStack service down - nova-api Short name ---------- -dovetail.ha.tc001.nova-api_service_down +dovetail.ha.nova_api Use case specification ---------------------- @@ -102,6 +102,7 @@ Test preconditions There is more than one controller node, which is providing the "nova-api" service for API end-point. + Denoted a controller node as Node1 in the following configuration. @@ -169,8 +170,10 @@ Post conditions --------------- Restart the process of "nova-api" if they are not running. -Delete image with "openstack image delete test-cirros" -Delete flavor with "openstack flavor delete m1.test" + +Delete image with "openstack image delete test-cirros". + +Delete flavor with "openstack flavor delete m1.test". --------------------------------------------------------------------- @@ -180,7 +183,7 @@ Test Case 2 - Controller node OpenStack service down - neutron-server Short name ---------- -dovetail.ha.tc002.neutron-server_service_down +dovetail.ha.neutron_server Use case specification ---------------------- @@ -196,6 +199,7 @@ Test preconditions There is more than one controller node, which is providing the "neutron-server" service for API end-point. + Denoted a controller node as Node1 in the following configuration. Basic test flow execution description and pass/fail criteria @@ -264,7 +268,7 @@ Test Case 3 - Controller node OpenStack service down - keystone Short name ---------- -dovetail.ha.tc003.keystone_service_down +dovetail.ha.keystone Use case specification ---------------------- @@ -280,6 +284,7 @@ Test preconditions There is more than one controller node, which is providing the "keystone" service for API end-point. + Denoted a controller node as Node1 in the following configuration. Basic test flow execution description and pass/fail criteria @@ -342,7 +347,7 @@ Test Case 4 - Controller node OpenStack service down - glance-api Short name ---------- -dovetail.ha.tc004.glance-api_service_down +dovetail.ha.glance_api Use case specification ---------------------- @@ -358,6 +363,7 @@ Test preconditions There is more than one controller node, which is providing the "glance-api" service for API end-point. + Denoted a controller node as Node1 in the following configuration. @@ -430,7 +436,7 @@ Test Case 5 - Controller node OpenStack service down - cinder-api Short name ---------- -dovetail.ha.tc005.cinder-api_service_down +dovetail.ha.cinder_api Use case specification ---------------------- @@ -446,6 +452,7 @@ Test preconditions There is more than one controller node, which is providing the "cinder-api" service for API end-point. + Denoted a controller node as Node1 in the following configuration. Basic test flow execution description and pass/fail criteria @@ -509,7 +516,7 @@ Test Case 6 - Controller Node CPU Overload High Availability Short name ---------- -dovetail.ha.tc006.cpu_overload +dovetail.ha.cpu_load Use case specification ---------------------- @@ -526,6 +533,7 @@ Test preconditions There is more than one controller node, which is providing the "cinder-api", "neutron-server", "glance-api" and "keystone" services for API end-point. + Denoted a controller node as Node1 in the following configuration. Basic test flow execution description and pass/fail criteria @@ -594,7 +602,7 @@ Test Case 7 - Controller Node Disk I/O Overload High Availability Short name ---------- -dovetail.ha.tc007.disk_I/O_overload +dovetail.ha.disk_load Use case specification ---------------------- @@ -668,16 +676,16 @@ Test Case 8 - Controller Load Balance as a Service High Availability Short name ---------- -dovetail.ha.tc008.load_balance_service_down +dovetail.ha.haproxy Use case specification ---------------------- -This test verifies the high availability of "load balancer" service. When -the "load balancer" service of a specified controller node is killed, whether -"load balancer" service on other controller nodes will work, and whether the -controller node will restart the "load balancer" service are checked. This -test case kills the processes of "load balancer" service on the selected +This test verifies the high availability of "haproxy" service. When +the "haproxy" service of a specified controller node is killed, whether +"haproxy" service on other controller nodes will work, and whether the +controller node will restart the "haproxy" service are checked. This +test case kills the processes of "haproxy" service on the selected controller node, then checks whether the request of the related OpenStack command is processed with no failure and whether the killed processes are recovered. @@ -685,8 +693,10 @@ recovered. Test preconditions ------------------ -There is more than one controller node, which is providing the "load balancer" -service for rest-api. Denoted as Node1 in the following configuration. +There is more than one controller node, which is providing the "haproxy" +service for rest-api. + +Denoted as Node1 in the following configuration. Basic test flow execution description and pass/fail criteria ------------------------------------------------------------ @@ -694,33 +704,32 @@ Basic test flow execution description and pass/fail criteria Methodology for monitoring high availability '''''''''''''''''''''''''''''''''''''''''''' -The high availability of "load balancer" service is evaluated by monitoring +The high availability of "haproxy" service is evaluated by monitoring service outage time and process outage time Service outage time is tested by continuously executing "openstack image list" command in loop and checking if the response of the command request is returned with no failure. -When the response fails, the "load balancer" service is considered in outage. +When the response fails, the "haproxy" service is considered in outage. The time between the first response failure and the last response failure is considered as service outage time. -Process outage time is tested by checking the status of processes of "load -balancer" service on the selected controller node. The time of those processes +Process outage time is tested by checking the status of processes of "haproxy" +service on the selected controller node. The time of those processes being killed to the time of those processes being recovered is the process outage time. -Process recovery is verified by checking the existence of processes of "load -balancer" service. +Process recovery is verified by checking the existence of processes of "haproxy" service. Test execution '''''''''''''' * Test action 1: Connect to Node1 through SSH, and check that processes of - "load balancer" service are running on Node1 -* Test action 2: Start two monitors: one for processes of "load balancer" + "haproxy" service are running on Node1 +* Test action 2: Start two monitors: one for processes of "haproxy" service and the other for "openstack image list" command. Each monitor will run as an independent process * Test action 3: Connect to Node1 through SSH, and then kill the processes of - "load balancer" service + "haproxy" service * Test action 4: Continuously measure service outage time from the monitor until the service outage time is more than 5s * Test action 5: Continuously measure process outage time from the monitor until @@ -737,7 +746,8 @@ A negative result will be generated if the above is not met in completion. Post conditions --------------- -Restart the processes of "load balancer" if they are not running. + +Restart the processes of "haproxy" if they are not running. diff --git a/docs/testing/user/testspecification/index.rst b/docs/testing/user/testspecification/index.rst index 2a8298c9..eba42d54 100644 --- a/docs/testing/user/testspecification/index.rst +++ b/docs/testing/user/testspecification/index.rst @@ -18,7 +18,7 @@ associated test specification. All tests in the OVP are required to fulfill a specific set of criteria in order that the OVP is able to provide a fair assessment of the system under -test. Test requirements are described in the 'Test Case Requirements'_ +test. Test requirements are described in the :ref:dovetail-test_case_requirements document. All tests areas addressed in the OVP are covered in the following test @@ -28,16 +28,11 @@ specification documents. :maxdepth: 1 ./highavailability/index.rst - ./vimoperationscompute/index.rst - ./vimoperationsidentity/index.rst - ./vimoperationsimage/index.rst - ./vimoperationsnetwork/index.rst - ./vimoperationsvolume/index.rst + ./tempest_osinterop/index.rst ./vping/index.rst - ./ipv6/index.rst - ./forwardingpackets/index.rst - ./securitygroup/index.rst - ./dynamicnetwork/index.rst - ./machinelifecycle/index.rst - ./multiplenodes/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 diff --git a/docs/testing/user/testspecification/tempest_ipv6/index.rst b/docs/testing/user/testspecification/tempest_ipv6/index.rst new file mode 100644 index 00000000..d78370c8 --- /dev/null +++ b/docs/testing/user/testspecification/tempest_ipv6/index.rst @@ -0,0 +1,140 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV + +======================== +IPv6 test specification +======================== + +Scope +===== + +The IPv6 test area will evaluate the ability for a SUT to support IPv6 +Tenant Network features and functionality. The tests in this test area will +evaluate, + +- network, subnet, port, router API CRUD operations +- interface add and remove operations +- security group and security group rule API CRUD operations +- IPv6 address assignment with dual stack, dual net, multiprefix in mode DHCPv6 stateless or SLAAC + +References +================ + +- upstream openstack API reference + + - http://developer.openstack.org/api-ref + +- upstream openstack IPv6 reference + + - https://docs.openstack.org/newton/networking-guide/config-ipv6.html + +Definitions and abbreviations +============================= + +The following terms and abbreviations are used in conjunction with this test area + +- API - Application Programming Interface +- CIDR - Classless Inter-Domain Routing +- CRUD - Create, Read, Update, and Delete +- DHCP - Dynamic Host Configuration Protocol +- DHCPv6 - Dynamic Host Configuration Protocol version 6 +- ICMP - Internet Control Message Protocol +- NFVI - Network Functions Virtualization Infrastructure +- NIC - Network Interface Controller +- RA - Router Advertisements +- radvd - The Router Advertisement Daemon +- SDN - Software Defined Network +- SLAAC - Stateless Address Auto Configuration +- TCP - Transmission Control Protocol +- UDP - User Datagram Protocol +- VM - Virtual Machine +- vNIC - virtual Network Interface Card + +System Under Test (SUT) +======================= + +The system under test is assumed to be the NFVI and VIM deployed with a Pharos compliant infrastructure. + +Test Area Structure +==================== + +The test area is structured based on network, port and subnet operations. Each test case +is able to run independently, i.e. irrelevant of the state created by a previous test. + +Test Descriptions +================= + +API Used and Reference +---------------------- + +Networks: https://developer.openstack.org/api-ref/networking/v2/index.html#networks + +- show network details +- update network +- delete network +- list networks +- create netowrk +- bulk create networks + +Subnets: https://developer.openstack.org/api-ref/networking/v2/index.html#subnets + +- list subnets +- create subnet +- bulk create subnet +- show subnet details +- update subnet +- delete subnet + +Routers and interface: https://developer.openstack.org/api-ref/networking/v2/index.html#routers-routers + +- list routers +- create router +- show router details +- update router +- delete router +- add interface to router +- remove interface from router + +Ports: https://developer.openstack.org/api-ref/networking/v2/index.html#ports + +- show port details +- update port +- delete port +- list port +- create port +- bulk create ports + +Security groups: https://developer.openstack.org/api-ref/networking/v2/index.html#security-groups-security-groups + +- list security groups +- create security groups +- show security group +- update security group +- delete security group + +Security groups rules: https://developer.openstack.org/api-ref/networking/v2/index.html#security-group-rules-security-group-rules + +- list security group rules +- create security group rule +- show security group rule +- delete security group rule + +Servers: https://developer.openstack.org/api-ref/compute/ + +- list servers +- create server +- create multiple servers +- list servers detailed +- show server details +- update server +- delete server + +All IPv6 api and scenario test cases addressed in OVP are covered in the +following test specification documents. + +.. toctree:: + :maxdepth: 2 + + ipv6_api.rst + ipv6_scenario.rst diff --git a/docs/testing/user/testspecification/ipv6/index.rst b/docs/testing/user/testspecification/tempest_ipv6/ipv6_api.rst index 0ede0a3d..79005329 100644 --- a/docs/testing/user/testspecification/ipv6/index.rst +++ b/docs/testing/user/testspecification/tempest_ipv6/ipv6_api.rst @@ -2,137 +2,6 @@ .. http://creativecommons.org/licenses/by/4.0 .. (c) OPNFV -======================== -IPv6 test specification -======================== - -.. toctree:: - :maxdepth: 2 - -Scope -===== - -The IPv6 test area will evaluate the ability for a SUT to support IPv6 -Tenant Network features and functionality. The tests in this test area will -evaluate, - -- network, subnet, port, router API CRUD operations -- interface add and remove operations -- security group and security group rule API CRUD operations -- IPv6 address assignment with dual stack, dual net, multiprefix in mode DHCPv6 stateless or SLAAC - -References -================ - -- upstream openstack API reference - - - http://developer.openstack.org/api-ref - -- upstream openstack IPv6 reference - - - https://docs.openstack.org/newton/networking-guide/config-ipv6.html - -Definitions and abbreviations -============================= - -The following terms and abbreviations are used in conjunction with this test area - -- API - Application Programming Interface -- CIDR - Classless Inter-Domain Routing -- CRUD - Create, Read, Update, and Delete -- DHCP - Dynamic Host Configuration Protocol -- DHCPv6 - Dynamic Host Configuration Protocol version 6 -- ICMP - Internet Control Message Protocol -- NFVI - Network Functions Virtualization Infrastructure -- NIC - Network Interface Controller -- RA - Router Advertisements -- radvd - The Router Advertisement Daemon -- SDN - Software Defined Network -- SLAAC - Stateless Address Auto Configuration -- TCP - Transmission Control Protocol -- UDP - User Datagram Protocol -- VM - Virtual Machine -- vNIC - virtual Network Interface Card - -System Under Test (SUT) -======================= - -The system under test is assumed to be the NFVI and VIM deployed with a Pharos compliant infrastructure. - -Test Area Structure -==================== - -The test area is structured based on network, port and subnet operations. Each test case -is able to run independently, i.e. irrelevant of the state created by a previous test. - -Test Descriptions -================= - -API Used and Reference ----------------------- - -Networks: https://developer.openstack.org/api-ref/networking/v2/index.html#networks - -- show network details -- update network -- delete network -- list networks -- create netowrk -- bulk create networks - -Subnets: https://developer.openstack.org/api-ref/networking/v2/index.html#subnets - -- list subnets -- create subnet -- bulk create subnet -- show subnet details -- update subnet -- delete subnet - -Routers and interface: https://developer.openstack.org/api-ref/networking/v2/index.html#routers-routers - -- list routers -- create router -- show router details -- update router -- delete router -- add interface to router -- remove interface from router - -Ports: https://developer.openstack.org/api-ref/networking/v2/index.html#ports - -- show port details -- update port -- delete port -- list port -- create port -- bulk create ports - -Security groups: https://developer.openstack.org/api-ref/networking/v2/index.html#security-groups-security-groups - -- list security groups -- create security groups -- show security group -- update security group -- delete security group - -Security groups rules: https://developer.openstack.org/api-ref/networking/v2/index.html#security-group-rules-security-group-rules - -- list security group rules -- create security group rule -- show security group rule -- delete security group rule - -Servers: https://developer.openstack.org/api-ref/compute/ - -- list servers -- create server -- create multiple servers -- list servers detailed -- show server details -- update server -- delete server - ------------------------------------------------------------------ Test Case 1 - Create and Delete Bulk Network, IPv6 Subnet and Port ------------------------------------------------------------------ @@ -140,7 +9,7 @@ Test Case 1 - Create and Delete Bulk Network, IPv6 Subnet and Port Short name ---------- -dovetail.ipv6.tc001.bulk_network_subnet_port_create_delete +dovetail.tempest.ipv6_api.bulk_network_subnet_port_create_delete Use case specification ---------------------- @@ -215,7 +84,7 @@ Test Case 2 - Create, Update and Delete an IPv6 Network and Subnet Short name ----------- -dovetail.ipv6.tc002.network_subnet_create_update_delete +dovetail.tempest.ipv6_api.network_subnet_create_update_delete Use case specification ---------------------- @@ -279,7 +148,7 @@ Test Case 3 - Check External Network Visibility Short name ----------- -dovetail.ipv6.tc003.external_network_visibility +dovetail.tempest.ipv6_api.external_network_visibility Use case specification ---------------------- @@ -340,7 +209,7 @@ Test Case 4 - List IPv6 Networks and Subnets Short name ----------- -dovetail.ipv6.tc004.network_subnet_list +dovetail.tempest.ipv6_api.network_subnet_list Use case specification ---------------------- @@ -399,7 +268,7 @@ Test Case 5 - Show Details of an IPv6 Network and Subnet Short name ---------- -dovetail.ipv6.tc005.network_subnet_show +dovetail.tempest.ipv6_api.network_subnet_show Use case specification ---------------------- @@ -459,7 +328,7 @@ Test Case 6 - Create an IPv6 Port in Allowed Allocation Pools Short name ---------- -dovetail.ipv6.tc006.port_create_in_allocation_pool +dovetail.tempest.ipv6_api.port_create_in_allocation_pool Use case specification ---------------------- @@ -524,7 +393,7 @@ Test Case 7 - Create an IPv6 Port with Empty Security Groups Short name ----------- -dovetail.ipv6.tc007.port_create_empty_security_group +dovetail.tempest.ipv6_api.port_create_empty_security_group Use case specification ---------------------- @@ -581,7 +450,7 @@ Test Case 8 - Create, Update and Delete an IPv6 Port Short name ---------- -dovetail.ipv6.tc008.port_create_update_delete +dovetail.tempest.ipv6_api.port_create_update_delete Use case specification ---------------------- @@ -640,7 +509,7 @@ Test Case 9 - List IPv6 Ports Short name ---------- -dovetail.ipv6.tc009.port_list +dovetail.tempest.ipv6_api.port_list Use case specification ---------------------- @@ -693,7 +562,7 @@ Test Case 10 - Show Key/Valus Details of an IPv6 Port Short name ---------- -dovetail.ipv6.tc010.port_show_details +dovetail.tempest.ipv6_api.port_show_details Use case specification ---------------------- @@ -754,7 +623,7 @@ Test Case 11 - Add Multiple Interfaces for an IPv6 Router Short name ----------- -dovetail.ipv6.tc011.router_add_multiple_interface +dovetail.tempest.ipv6_api.router_add_multiple_interface Use case specification ---------------------- @@ -819,7 +688,7 @@ Test Case 12 - Add and Remove an IPv6 Router Interface with port_id Short name ---------- -dovetail.ipv6.tc012.router_interface_add_remove_with_port +dovetail.tempest.ipv6_api.router_interface_add_remove_with_port Use case specification ---------------------- @@ -879,7 +748,7 @@ Test Case 13 - Add and Remove an IPv6 Router Interface with subnet_id Short name ---------- -dovetail.ipv6.tc013.router_interface_add_remove +dovetail.tempest.ipv6_api.router_interface_add_remove Use case specification ---------------------- @@ -947,7 +816,7 @@ Test Case 14 - Create, Show, List, Update and Delete an IPv6 router Short name ---------- -dovetail.ipv6.tc014.router_create_show_list_update_delete +dovetail.tempest.ipv6_api.router_create_show_list_update_delete Use case specification ---------------------- @@ -1011,7 +880,7 @@ Test Case 15 - Create, List, Update, Show and Delete an IPv6 security group Short name ---------- -dovetail.ipv6.tc015.security_group_create_list_update_show_delete +dovetail.tempest.ipv6_api.security_group_create_list_update_show_delete Use case specification ---------------------- @@ -1069,7 +938,7 @@ Test Case 16 - Create, Show and Delete IPv6 security group rule Short name ---------- -dovetail.ipv6.tc016.security_group_rule_create_show_delete +dovetail.tempest.ipv6_api.security_group_rule_create_show_delete Use case specification ---------------------- @@ -1127,7 +996,7 @@ Test Case 17 - List IPv6 Security Groups Short name ---------- -dovetail.ipv6.tc017.security_group_list +dovetail.tempest.ipv6_api.security_group_list Use case specification ---------------------- @@ -1164,624 +1033,3 @@ Post conditions --------------- None - ----------------------------------------------------------------------------- -Test Case 18 - IPv6 Address Assignment - Dual Stack, SLAAC, DHCPv6 Stateless ----------------------------------------------------------------------------- - -Short name ----------- - -dovetail.ipv6.tc018.dhcpv6_stateless - -Use case specification ----------------------- - -This test case evaluates IPv6 address assignment in ipv6_ra_mode 'dhcpv6_stateless' -and ipv6_address_mode 'dhcpv6_stateless'. -In this case, guest instance obtains IPv6 address from OpenStack managed radvd -using SLAAC and optional info from dnsmasq using DHCPv6 stateless. This test case then -verifies the ping6 available VM can ping the other VM's v4 and v6 addresses -as well as the v6 subnet's gateway ip in the same network, the reference is - -tempest.scenario.test_network_v6.TestGettingAddress.test_dhcp6_stateless_from_os - -Test preconditions ------------------- - -There should exist a public router or a public network. - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -''''''''''''''' - -* Test action 1: Create one network, storing the "id" parameter returned in the response -* Test action 2: Create one IPv4 subnet of the created network, storing the "id" - parameter returned in the response -* Test action 3: If there exists a public router, use it as the router. Otherwise, - use the public network to create a router -* Test action 4: Connect the IPv4 subnet to the router, using the stored IPv4 subnet id -* Test action 5: Create one IPv6 subnet of the network created in test action 1 in - ipv6_ra_mode 'dhcpv6_stateless' and ipv6_address_mode 'dhcpv6_stateless', - storing the "id" parameter returned in the response -* Test action 6: Connect the IPv6 subnet to the router, using the stored IPv6 subnet id -* Test action 7: Boot two VMs on this network, storing the "id" parameters returned in the response -* **Test assertion 1:** The vNIC of each VM gets one v4 address and one v6 address actually assigned -* **Test assertion 2:** Each VM can ping the other's v4 private address -* **Test assertion 3:** The ping6 available VM can ping the other's v6 address - as well as the v6 subnet's gateway ip -* Test action 8: Delete the 2 VMs created in test action 7, using the stored ids -* Test action 9: List all VMs, verifying the ids are no longer present -* **Test assertion 4:** The two "id" parameters are not present in the VM list -* Test action 10: Delete the IPv4 subnet created in test action 2, using the stored id -* Test action 11: Delete the IPv6 subnet created in test action 5, using the stored id -* Test action 12: List all subnets, verifying the ids are no longer present -* **Test assertion 5:** The "id" parameters of IPv4 and IPv6 are not present in the list -* Test action 13: Delete the network created in test action 1, using the stored id -* Test action 14: List all networks, verifying the id is no longer present -* **Test assertion 6:** The "id" parameter is not present in the network list - -Pass / fail criteria -''''''''''''''''''''' - -This test evaluates the ability to assign IPv6 addresses in ipv6_ra_mode -'dhcpv6_stateless' and ipv6_address_mode 'dhcpv6_stateless', -and verify the ping6 available VM can ping the other VM's v4 and v6 addresses as well as -the v6 subnet's gateway ip in the same network. Specifically it verifies that: - -* The IPv6 addresses in mode 'dhcpv6_stateless' assigned successfully -* The VM can ping the other VM's IPv4 and IPv6 private addresses as well as the v6 subnet's gateway ip -* All items created using create commands are able to be removed using the returned identifiers - -Post conditions ---------------- - -None - --------------------------------------------------------------------------------------- -Test Case 19 - IPv6 Address Assignment - Dual Net, Dual Stack, SLAAC, DHCPv6 Stateless --------------------------------------------------------------------------------------- - -Short name ----------- - -dovetail.ipv6.tc019.dualnet_dhcpv6_stateless - -Use case specification ----------------------- - -This test case evaluates IPv6 address assignment in ipv6_ra_mode 'dhcpv6_stateless' -and ipv6_address_mode 'dhcpv6_stateless'. -In this case, guest instance obtains IPv6 address from OpenStack managed radvd -using SLAAC and optional info from dnsmasq using DHCPv6 stateless. This test case then -verifies the ping6 available VM can ping the other VM's v4 address in one network -and v6 address in another network as well as the v6 subnet's gateway ip, the reference is - -tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_dhcp6_stateless_from_os - -Test preconditions ------------------- - -There should exists a public router or a public network. - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -''''''''''''''' - -* Test action 1: Create one network, storing the "id" parameter returned in the response -* Test action 2: Create one IPv4 subnet of the created network, storing the "id" - parameter returned in the response -* Test action 3: If there exists a public router, use it as the router. Otherwise, - use the public network to create a router -* Test action 4: Connect the IPv4 subnet to the router, using the stored IPv4 subnet id -* Test action 5: Create another network, storing the "id" parameter returned in the response -* Test action 6: Create one IPv6 subnet of network created in test action 5 in - ipv6_ra_mode 'dhcpv6_stateless' and ipv6_address_mode 'dhcpv6_stateless', - storing the "id" parameter returned in the response -* Test action 7: Connect the IPv6 subnet to the router, using the stored IPv6 subnet id -* Test action 8: Boot two VMs on these two networks, storing the "id" parameters returned in the response -* Test action 9: Turn on 2nd NIC of each VM for the network created in test action 5 -* **Test assertion 1:** The 1st vNIC of each VM gets one v4 address assigned and - the 2nd vNIC of each VM gets one v6 address actually assigned -* **Test assertion 2:** Each VM can ping the other's v4 private address -* **Test assertion 3:** The ping6 available VM can ping the other's v6 address - as well as the v6 subnet's gateway ip -* Test action 10: Delete the 2 VMs created in test action 8, using the stored ids -* Test action 11: List all VMs, verifying the ids are no longer present -* **Test assertion 4:** The two "id" parameters are not present in the VM list -* Test action 12: Delete the IPv4 subnet created in test action 2, using the stored id -* Test action 13: Delete the IPv6 subnet created in test action 6, using the stored id -* Test action 14: List all subnets, verifying the ids are no longer present -* **Test assertion 5:** The "id" parameters of IPv4 and IPv6 are not present in the list -* Test action 15: Delete the 2 networks created in test action 1 and 5, using the stored ids -* Test action 16: List all networks, verifying the ids are no longer present -* **Test assertion 6:** The two "id" parameters are not present in the network list - -Pass / fail criteria -'''''''''''''''''''' - -This test evaluates the ability to assign IPv6 addresses in ipv6_ra_mode 'dhcpv6_stateless' -and ipv6_address_mode 'dhcpv6_stateless', and verify the ping6 available VM can ping -the other VM's v4 address in one network and v6 address in another network as well as -the v6 subnet's gateway ip. Specifically it verifies that: - -* The IPv6 addresses in mode 'dhcpv6_stateless' assigned successfully -* The VM can ping the other VM's IPv4 address in one network and IPv6 address in another - network as well as the v6 subnet's gateway ip -* All items created using create commands are able to be removed using the returned identifiers - -Post conditions ---------------- - -None - ------------------------------------------------------------------------------------------------ -Test Case 20 - IPv6 Address Assignment - Multiple Prefixes, Dual Stack, SLAAC, DHCPv6 Stateless ------------------------------------------------------------------------------------------------ - -Short name ----------- - -dovetail.ipv6.tc020.multiple_prefixes_dhcpv6_stateless - -Use case specification ----------------------- - -This test case evaluates IPv6 address assignment in ipv6_ra_mode 'dhcpv6_stateless' -and ipv6_address_mode 'dhcpv6_stateless'. -In this case, guest instance obtains IPv6 addresses from OpenStack managed radvd -using SLAAC and optional info from dnsmasq using DHCPv6 stateless. This test case then -verifies the ping6 available VM can ping the other VM's one v4 address and two v6 -addresses with different prefixes as well as the v6 subnets' gateway ips in the -same network, the reference is - -tempest.scenario.test_network_v6.TestGettingAddress.test_multi_prefix_dhcpv6_stateless - -Test preconditions ------------------- - -There should exist a public router or a public network. - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -''''''''''''''' - -* Test action 1: Create one network, storing the "id" parameter returned in the response -* Test action 2: Create one IPv4 subnet of the created network, storing the "id" - parameter returned in the response -* Test action 3: If there exists a public router, use it as the router. Otherwise, - use the public network to create a router -* Test action 4: Connect the IPv4 subnet to the router, using the stored IPv4 subnet id -* Test action 5: Create two IPv6 subnets of the network created in test action 1 in - ipv6_ra_mode 'dhcpv6_stateless' and ipv6_address_mode 'dhcpv6_stateless', - storing the "id" parameters returned in the response -* Test action 6: Connect the two IPv6 subnets to the router, using the stored IPv6 subnet ids -* Test action 7: Boot two VMs on this network, storing the "id" parameters returned in the response -* **Test assertion 1:** The vNIC of each VM gets one v4 address and two v6 addresses with - different prefixes actually assigned -* **Test assertion 2:** Each VM can ping the other's v4 private address -* **Test assertion 3:** The ping6 available VM can ping the other's v6 addresses - as well as the v6 subnets' gateway ips -* Test action 8: Delete the 2 VMs created in test action 7, using the stored ids -* Test action 9: List all VMs, verifying the ids are no longer present -* **Test assertion 4:** The two "id" parameters are not present in the VM list -* Test action 10: Delete the IPv4 subnet created in test action 2, using the stored id -* Test action 11: Delete two IPv6 subnets created in test action 5, using the stored ids -* Test action 12: List all subnets, verifying the ids are no longer present -* **Test assertion 5:** The "id" parameters of IPv4 and IPv6 are not present in the list -* Test action 13: Delete the network created in test action 1, using the stored id -* Test action 14: List all networks, verifying the id is no longer present -* **Test assertion 6:** The "id" parameter is not present in the network list - -Pass / fail criteria -''''''''''''''''''''' - -This test evaluates the ability to assign IPv6 addresses in ipv6_ra_mode 'dhcpv6_stateless' -and ipv6_address_mode 'dhcpv6_stateless', -and verify the ping6 available VM can ping the other VM's v4 address and two -v6 addresses with different prefixes as well as the v6 subnets' gateway ips in the same network. -Specifically it verifies that: - -* The different prefixes IPv6 addresses in mode 'dhcpv6_stateless' assigned successfully -* The VM can ping the other VM's IPv4 and IPv6 private addresses as well as the v6 subnets' gateway ips -* All items created using create commands are able to be removed using the returned identifiers - -Post conditions ---------------- - -None - ---------------------------------------------------------------------------------------------------------- -Test Case 21 - IPv6 Address Assignment - Dual Net, Multiple Prefixes, Dual Stack, SLAAC, DHCPv6 Stateless ---------------------------------------------------------------------------------------------------------- - -Short name ----------- - -dovetail.ipv6.tc021.dualnet_multiple_prefixes_dhcpv6_stateless - -Use case specification ----------------------- - -This test case evaluates IPv6 address assignment in ipv6_ra_mode 'dhcpv6_stateless' -and ipv6_address_mode 'dhcpv6_stateless'. -In this case, guest instance obtains IPv6 addresses from OpenStack managed radvd -using SLAAC and optional info from dnsmasq using DHCPv6 stateless. This test case then -verifies the ping6 available VM can ping the other VM's v4 address in one network -and two v6 addresses with different prefixes in another network as well as the -v6 subnets' gateway ips, the reference is - -tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_multi_prefix_dhcpv6_stateless - -Test preconditions ------------------- - -There should exist a public router or a public network. - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -''''''''''''''' - -* Test action 1: Create one network, storing the "id" parameter returned in the response -* Test action 2: Create one IPv4 subnet of the created network, storing the "id" - parameter returned in the response -* Test action 3: If there exists a public router, use it as the router. Otherwise, - use the public network to create a router -* Test action 4: Connect the IPv4 subnet to the router, using the stored IPv4 subnet id -* Test action 5: Create another network, storing the "id" parameter returned in the response -* Test action 6: Create two IPv6 subnets of network created in test action 5 in - ipv6_ra_mode 'dhcpv6_stateless' and ipv6_address_mode 'dhcpv6_stateless', - storing the "id" parameters returned in the response -* Test action 7: Connect the two IPv6 subnets to the router, using the stored IPv6 subnet ids -* Test action 8: Boot two VMs on these two networks, storing the "id" parameters returned in the response -* Test action 9: Turn on 2nd NIC of each VM for the network created in test action 5 -* **Test assertion 1:** The vNIC of each VM gets one v4 address and two v6 addresses - with different prefixes actually assigned -* **Test assertion 2:** Each VM can ping the other's v4 private address -* **Test assertion 3:** The ping6 available VM can ping the other's v6 addresses - as well as the v6 subnets' gateway ips -* Test action 10: Delete the 2 VMs created in test action 8, using the stored ids -* Test action 11: List all VMs, verifying the ids are no longer present -* **Test assertion 4:** The two "id" parameters are not present in the VM list -* Test action 12: Delete the IPv4 subnet created in test action 2, using the stored id -* Test action 13: Delete two IPv6 subnets created in test action 6, using the stored ids -* Test action 14: List all subnets, verifying the ids are no longer present -* **Test assertion 5:** The "id" parameters of IPv4 and IPv6 are not present in the list -* Test action 15: Delete the 2 networks created in test action 1 and 5, using the stored ids -* Test action 16: List all networks, verifying the ids are no longer present -* **Test assertion 6:** The two "id" parameters are not present in the network list - -Pass / fail criteria -''''''''''''''''''''' - -This test evaluates the ability to assign IPv6 addresses in ipv6_ra_mode 'dhcpv6_stateless' -and ipv6_address_mode 'dhcpv6_stateless', -and verify the ping6 available VM can ping the other VM's v4 address in one network and two -v6 addresses with different prefixes in another network as well as the v6 subnets' -gateway ips. Specifically it verifies that: - -* The IPv6 addresses in mode 'dhcpv6_stateless' assigned successfully -* The VM can ping the other VM's IPv4 and IPv6 private addresses as well as the v6 subnets' gateway ips -* All items created using create commands are able to be removed using the returned identifiers - -Post conditions ---------------- - -None - ----------------------------------------------------------- -Test Case 22 - IPv6 Address Assignment - Dual Stack, SLAAC ----------------------------------------------------------- - -Short name ----------- - -dovetail.ipv6.tc022.slaac - -Use case specification ----------------------- - -This test case evaluates IPv6 address assignment in ipv6_ra_mode 'slaac' and -ipv6_address_mode 'slaac'. -In this case, guest instance obtains IPv6 address from OpenStack managed radvd -using SLAAC. This test case then verifies the ping6 available VM can ping the other -VM's v4 and v6 addresses as well as the v6 subnet's gateway ip in the -same network, the reference is - -tempest.scenario.test_network_v6.TestGettingAddress.test_slaac_from_os - -Test preconditions ------------------- - -There should exist a public router or a public network. - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -''''''''''''''' - -* Test action 1: Create one network, storing the "id" parameter returned in the response -* Test action 2: Create one IPv4 subnet of the created network, storing the "id" - parameter returned in the response -* Test action 3: If there exists a public router, use it as the router. Otherwise, - use the public network to create a router -* Test action 4: Connect the IPv4 subnet to the router, using the stored IPv4 subnet id -* Test action 5: Create one IPv6 subnet of the network created in test action 1 in - ipv6_ra_mode 'slaac' and ipv6_address_mode 'slaac', storing the "id" parameter returned in the response -* Test action 6: Connect the IPv6 subnet to the router, using the stored IPv6 subnet id -* Test action 7: Boot two VMs on this network, storing the "id" parameters returned in the response -* **Test assertion 1:** The vNIC of each VM gets one v4 address and one v6 address actually assigned -* **Test assertion 2:** Each VM can ping the other's v4 private address -* **Test assertion 3:** The ping6 available VM can ping the other's v6 address - as well as the v6 subnet's gateway ip -* Test action 8: Delete the 2 VMs created in test action 7, using the stored ids -* Test action 9: List all VMs, verifying the ids are no longer present -* **Test assertion 4:** The two "id" parameters are not present in the VM list -* Test action 10: Delete the IPv4 subnet created in test action 2, using the stored id -* Test action 11: Delete the IPv6 subnet created in test action 5, using the stored id -* Test action 12: List all subnets, verifying the ids are no longer present -* **Test assertion 5:** The "id" parameters of IPv4 and IPv6 are not present in the list -* Test action 13: Delete the network created in test action 1, using the stored id -* Test action 14: List all networks, verifying the id is no longer present -* **Test assertion 6:** The "id" parameter is not present in the network list - -Pass / fail criteria -''''''''''''''''''''' - -This test evaluates the ability to assign IPv6 addresses in ipv6_ra_mode 'slaac' -and ipv6_address_mode 'slaac', -and verify the ping6 available VM can ping the other VM's v4 and v6 addresses as well as -the v6 subnet's gateway ip in the same network. Specifically it verifies that: - -* The IPv6 addresses in mode 'slaac' assigned successfully -* The VM can ping the other VM's IPv4 and IPv6 private addresses as well as the v6 subnet's gateway ip -* All items created using create commands are able to be removed using the returned identifiers - -Post conditions ---------------- - -None - --------------------------------------------------------------------- -Test Case 23 - IPv6 Address Assignment - Dual Net, Dual Stack, SLAAC --------------------------------------------------------------------- - -Short name ----------- - -dovetail.ipv6.tc023.dualnet_slaac - -Use case specification ----------------------- - -This test case evaluates IPv6 address assignment in ipv6_ra_mode 'slaac' and -ipv6_address_mode 'slaac'. -In this case, guest instance obtains IPv6 address from OpenStack managed radvd -using SLAAC. This test case then verifies the ping6 available VM can ping the other -VM's v4 address in one network and v6 address in another network as well as the -v6 subnet's gateway ip, the reference is - -tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_slaac_from_os - -Test preconditions ------------------- - -There should exist a public router or a public network. - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -''''''''''''''' - -* Test action 1: Create one network, storing the "id" parameter returned in the response -* Test action 2: Create one IPv4 subnet of the created network, storing the "id" - parameter returned in the response -* Test action 3: If there exists a public router, use it as the router. Otherwise, - use the public network to create a router -* Test action 4: Connect the IPv4 subnet to the router, using the stored IPv4 subnet id -* Test action 5: Create another network, storing the "id" parameter returned in the response -* Test action 6: Create one IPv6 subnet of network created in test action 5 in - ipv6_ra_mode 'slaac' and ipv6_address_mode 'slaac', storing the "id" parameter returned in the response -* Test action 7: Connect the IPv6 subnet to the router, using the stored IPv6 subnet id -* Test action 8: Boot two VMs on these two networks, storing the "id" parameters returned in the response -* Test action 9: Turn on 2nd NIC of each VM for the network created in test action 5 -* **Test assertion 1:** The 1st vNIC of each VM gets one v4 address assigned and - the 2nd vNIC of each VM gets one v6 address actually assigned -* **Test assertion 2:** Each VM can ping the other's v4 private address -* **Test assertion 3:** The ping6 available VM can ping the other's v6 address - as well as the v6 subnet's gateway ip -* Test action 10: Delete the 2 VMs created in test action 8, using the stored ids -* Test action 11: List all VMs, verifying the ids are no longer present -* **Test assertion 4:** The two "id" parameters are not present in the VM list -* Test action 12: Delete the IPv4 subnet created in test action 2, using the stored id -* Test action 13: Delete the IPv6 subnet created in test action 6, using the stored id -* Test action 14: List all subnets, verifying the ids are no longer present -* **Test assertion 5:** The "id" parameters of IPv4 and IPv6 are not present in the list -* Test action 15: Delete the 2 networks created in test action 1 and 5, using the stored ids -* Test action 16: List all networks, verifying the ids are no longer present -* **Test assertion 6:** The two "id" parameters are not present in the network list - -Pass / fail criteria -''''''''''''''''''''' - -This test evaluates the ability to assign IPv6 addresses in ipv6_ra_mode 'slaac' -and ipv6_address_mode 'slaac', -and verify the ping6 available VM can ping the other VM's v4 address in one network and -v6 address in another network as well as the v6 subnet's gateway ip. Specifically it verifies that: - -* The IPv6 addresses in mode 'slaac' assigned successfully -* The VM can ping the other VM's IPv4 address in one network and IPv6 address - in another network as well as the v6 subnet's gateway ip -* All items created using create commands are able to be removed using the returned identifiers - -Post conditions ---------------- - -None - ------------------------------------------------------------------------------ -Test Case 24 - IPv6 Address Assignment - Multiple Prefixes, Dual Stack, SLAAC ------------------------------------------------------------------------------ - -Short name ----------- - -dovetail.ipv6.tc024.multiple_prefixes_slaac - -Use case specification ----------------------- - -This test case evaluates IPv6 address assignment in ipv6_ra_mode 'slaac' and -ipv6_address_mode 'slaac'. -In this case, guest instance obtains IPv6 addresses from OpenStack managed radvd -using SLAAC. This test case then verifies the ping6 available VM can ping the other -VM's one v4 address and two v6 addresses with different prefixes as well as the v6 -subnets' gateway ips in the same network, the reference is - -tempest.scenario.test_network_v6.TestGettingAddress.test_multi_prefix_slaac - -Test preconditions ------------------- - -There should exists a public router or a public network. - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -''''''''''''''' - -* Test action 1: Create one network, storing the "id" parameter returned in the response -* Test action 2: Create one IPv4 subnet of the created network, storing the "id - parameter returned in the response -* Test action 3: If there exists a public router, use it as the router. Otherwise, - use the public network to create a router -* Test action 4: Connect the IPv4 subnet to the router, using the stored IPv4 subnet id -* Test action 5: Create two IPv6 subnets of the network created in test action 1 in - ipv6_ra_mode 'slaac' and ipv6_address_mode 'slaac', storing the "id" parameters returned in the response -* Test action 6: Connect the two IPv6 subnets to the router, using the stored IPv6 subnet ids -* Test action 7: Boot two VMs on this network, storing the "id" parameters returned in the response -* **Test assertion 1:** The vNIC of each VM gets one v4 address and two v6 addresses with - different prefixes actually assigned -* **Test assertion 2:** Each VM can ping the other's v4 private address -* **Test assertion 3:** The ping6 available VM can ping the other's v6 addresses - as well as the v6 subnets' gateway ips -* Test action 8: Delete the 2 VMs created in test action 7, using the stored ids -* Test action 9: List all VMs, verifying the ids are no longer present -* **Test assertion 4:** The two "id" parameters are not present in the VM list -* Test action 10: Delete the IPv4 subnet created in test action 2, using the stored id -* Test action 11: Delete two IPv6 subnets created in test action 5, using the stored ids -* Test action 12: List all subnets, verifying the ids are no longer present -* **Test assertion 5:** The "id" parameters of IPv4 and IPv6 are not present in the list -* Test action 13: Delete the network created in test action 1, using the stored id -* Test action 14: List all networks, verifying the id is no longer present -* **Test assertion 6:** The "id" parameter is not present in the network list - -Pass / fail criteria -''''''''''''''''''''' - -This test evaluates the ability to assign IPv6 addresses in ipv6_ra_mode 'slaac' -and ipv6_address_mode 'slaac', -and verify the ping6 available VM can ping the other VM's v4 address and two -v6 addresses with different prefixes as well as the v6 subnets' gateway ips in the same network. -Specifically it verifies that: - -* The different prefixes IPv6 addresses in mode 'slaac' assigned successfully -* The VM can ping the other VM's IPv4 and IPv6 private addresses as well as the v6 subnets' gateway ips -* All items created using create commands are able to be removed using the returned identifiers - -Post conditions ---------------- - -None - ---------------------------------------------------------------------------------------- -Test Case 25 - IPv6 Address Assignment - Dual Net, Dual Stack, Multiple Prefixes, SLAAC ---------------------------------------------------------------------------------------- - -Short name ----------- - -dovetail.ipv6.tc025.dualnet_multiple_prefixes_slaac - -Use case specification ----------------------- - -This test case evaluates IPv6 address assignment in ipv6_ra_mode 'slaac' and -ipv6_address_mode 'slaac'. -In this case, guest instance obtains IPv6 addresses from OpenStack managed radvd -using SLAAC. This test case then verifies the ping6 available VM can ping the other -VM's v4 address in one network and two v6 addresses with different prefixes in another -network as well as the v6 subnets' gateway ips, the reference is - -tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_multi_prefix_slaac - -Test preconditions ------------------- - -There should exist a public router or a public network. - -Basic test flow execution description and pass/fail criteria ------------------------------------------------------------- - -Test execution -''''''''''''''' - -* Test action 1: Create one network, storing the "id" parameter returned in the response -* Test action 2: Create one IPv4 subnet of the created network, storing the "id" - parameter returned in the response -* Test action 3: If there exists a public router, use it as the router. Otherwise, - use the public network to create a router -* Test action 4: Connect the IPv4 subnet to the router, using the stored IPv4 subnet id -* Test action 5: Create another network, storing the "id" parameter returned in the response -* Test action 6: Create two IPv6 subnets of network created in test action 5 in - ipv6_ra_mode 'slaac' and ipv6_address_mode 'slaac', storing the "id" parameters returned in the response -* Test action 7: Connect the two IPv6 subnets to the router, using the stored IPv6 subnet ids -* Test action 8: Boot two VMs on these two networks, storing the "id" parameters returned in the response -* Test action 9: Turn on 2nd NIC of each VM for the network created in test action 5 -* **Test assertion 1:** The vNIC of each VM gets one v4 address and two v6 addresses - with different prefixes actually assigned -* **Test assertion 2:** Each VM can ping the other's v4 private address -* **Test assertion 3:** The ping6 available VM can ping the other's v6 addresses - as well as the v6 subnets' gateway ips -* Test action 10: Delete the 2 VMs created in test action 8, using the stored ids -* Test action 11: List all VMs, verifying the ids are no longer present -* **Test assertion 4:** The two "id" parameters are not present in the VM list -* Test action 12: Delete the IPv4 subnet created in test action 2, using the stored id -* Test action 13: Delete two IPv6 subnets created in test action 6, using the stored ids -* Test action 14: List all subnets, verifying the ids are no longer present -* **Test assertion 5:** The "id" parameters of IPv4 and IPv6 are not present in the list -* Test action 15: Delete the 2 networks created in test action 1 and 5, using the stored ids -* Test action 16: List all networks, verifying the ids are no longer present -* **Test assertion 6:** The two "id" parameters are not present in the network list - -Pass / fail criteria -''''''''''''''''''''' - -This test evaluates the ability to assign IPv6 addresses in ipv6_ra_mode 'slaac' -and ipv6_address_mode 'slaac', -and verify the ping6 available VM can ping the other VM's v4 address in one network and two -v6 addresses with different prefixes in another network as well as the v6 subnets' gateway ips. -Specifically it verifies that: - -* The IPv6 addresses in mode 'slaac' assigned successfully -* The VM can ping the other VM's IPv4 and IPv6 private addresses as well as the v6 subnets' gateway ips -* All items created using create commands are able to be removed using the returned identifiers - -Post conditions ---------------- - -None - - - diff --git a/docs/testing/user/testspecification/tempest_ipv6/ipv6_scenario.rst b/docs/testing/user/testspecification/tempest_ipv6/ipv6_scenario.rst new file mode 100644 index 00000000..f3a279f0 --- /dev/null +++ b/docs/testing/user/testspecification/tempest_ipv6/ipv6_scenario.rst @@ -0,0 +1,624 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) OPNFV + +---------------------------------------------------------------------------- +Test Case 1 - IPv6 Address Assignment - Dual Stack, SLAAC, DHCPv6 Stateless +---------------------------------------------------------------------------- + +Short name +---------- + +dovetail.tempest.ipv6_scenario.dhcpv6_stateless + +Use case specification +---------------------- + +This test case evaluates IPv6 address assignment in ipv6_ra_mode 'dhcpv6_stateless' +and ipv6_address_mode 'dhcpv6_stateless'. +In this case, guest instance obtains IPv6 address from OpenStack managed radvd +using SLAAC and optional info from dnsmasq using DHCPv6 stateless. This test case then +verifies the ping6 available VM can ping the other VM's v4 and v6 addresses +as well as the v6 subnet's gateway ip in the same network, the reference is + +tempest.scenario.test_network_v6.TestGettingAddress.test_dhcp6_stateless_from_os + +Test preconditions +------------------ + +There should exist a public router or a public network. + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +''''''''''''''' + +* Test action 1: Create one network, storing the "id" parameter returned in the response +* Test action 2: Create one IPv4 subnet of the created network, storing the "id" + parameter returned in the response +* Test action 3: If there exists a public router, use it as the router. Otherwise, + use the public network to create a router +* Test action 4: Connect the IPv4 subnet to the router, using the stored IPv4 subnet id +* Test action 5: Create one IPv6 subnet of the network created in test action 1 in + ipv6_ra_mode 'dhcpv6_stateless' and ipv6_address_mode 'dhcpv6_stateless', + storing the "id" parameter returned in the response +* Test action 6: Connect the IPv6 subnet to the router, using the stored IPv6 subnet id +* Test action 7: Boot two VMs on this network, storing the "id" parameters returned in the response +* **Test assertion 1:** The vNIC of each VM gets one v4 address and one v6 address actually assigned +* **Test assertion 2:** Each VM can ping the other's v4 private address +* **Test assertion 3:** The ping6 available VM can ping the other's v6 address + as well as the v6 subnet's gateway ip +* Test action 8: Delete the 2 VMs created in test action 7, using the stored ids +* Test action 9: List all VMs, verifying the ids are no longer present +* **Test assertion 4:** The two "id" parameters are not present in the VM list +* Test action 10: Delete the IPv4 subnet created in test action 2, using the stored id +* Test action 11: Delete the IPv6 subnet created in test action 5, using the stored id +* Test action 12: List all subnets, verifying the ids are no longer present +* **Test assertion 5:** The "id" parameters of IPv4 and IPv6 are not present in the list +* Test action 13: Delete the network created in test action 1, using the stored id +* Test action 14: List all networks, verifying the id is no longer present +* **Test assertion 6:** The "id" parameter is not present in the network list + +Pass / fail criteria +''''''''''''''''''''' + +This test evaluates the ability to assign IPv6 addresses in ipv6_ra_mode +'dhcpv6_stateless' and ipv6_address_mode 'dhcpv6_stateless', +and verify the ping6 available VM can ping the other VM's v4 and v6 addresses as well as +the v6 subnet's gateway ip in the same network. Specifically it verifies that: + +* The IPv6 addresses in mode 'dhcpv6_stateless' assigned successfully +* The VM can ping the other VM's IPv4 and IPv6 private addresses as well as the v6 subnet's gateway ip +* All items created using create commands are able to be removed using the returned identifiers + +Post conditions +--------------- + +None + +-------------------------------------------------------------------------------------- +Test Case 2 - IPv6 Address Assignment - Dual Net, Dual Stack, SLAAC, DHCPv6 Stateless +-------------------------------------------------------------------------------------- + +Short name +---------- + +dovetail.tempest.ipv6_scenario.dualnet_dhcpv6_stateless + +Use case specification +---------------------- + +This test case evaluates IPv6 address assignment in ipv6_ra_mode 'dhcpv6_stateless' +and ipv6_address_mode 'dhcpv6_stateless'. +In this case, guest instance obtains IPv6 address from OpenStack managed radvd +using SLAAC and optional info from dnsmasq using DHCPv6 stateless. This test case then +verifies the ping6 available VM can ping the other VM's v4 address in one network +and v6 address in another network as well as the v6 subnet's gateway ip, the reference is + +tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_dhcp6_stateless_from_os + +Test preconditions +------------------ + +There should exists a public router or a public network. + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +''''''''''''''' + +* Test action 1: Create one network, storing the "id" parameter returned in the response +* Test action 2: Create one IPv4 subnet of the created network, storing the "id" + parameter returned in the response +* Test action 3: If there exists a public router, use it as the router. Otherwise, + use the public network to create a router +* Test action 4: Connect the IPv4 subnet to the router, using the stored IPv4 subnet id +* Test action 5: Create another network, storing the "id" parameter returned in the response +* Test action 6: Create one IPv6 subnet of network created in test action 5 in + ipv6_ra_mode 'dhcpv6_stateless' and ipv6_address_mode 'dhcpv6_stateless', + storing the "id" parameter returned in the response +* Test action 7: Connect the IPv6 subnet to the router, using the stored IPv6 subnet id +* Test action 8: Boot two VMs on these two networks, storing the "id" parameters returned in the response +* Test action 9: Turn on 2nd NIC of each VM for the network created in test action 5 +* **Test assertion 1:** The 1st vNIC of each VM gets one v4 address assigned and + the 2nd vNIC of each VM gets one v6 address actually assigned +* **Test assertion 2:** Each VM can ping the other's v4 private address +* **Test assertion 3:** The ping6 available VM can ping the other's v6 address + as well as the v6 subnet's gateway ip +* Test action 10: Delete the 2 VMs created in test action 8, using the stored ids +* Test action 11: List all VMs, verifying the ids are no longer present +* **Test assertion 4:** The two "id" parameters are not present in the VM list +* Test action 12: Delete the IPv4 subnet created in test action 2, using the stored id +* Test action 13: Delete the IPv6 subnet created in test action 6, using the stored id +* Test action 14: List all subnets, verifying the ids are no longer present +* **Test assertion 5:** The "id" parameters of IPv4 and IPv6 are not present in the list +* Test action 15: Delete the 2 networks created in test action 1 and 5, using the stored ids +* Test action 16: List all networks, verifying the ids are no longer present +* **Test assertion 6:** The two "id" parameters are not present in the network list + +Pass / fail criteria +'''''''''''''''''''' + +This test evaluates the ability to assign IPv6 addresses in ipv6_ra_mode 'dhcpv6_stateless' +and ipv6_address_mode 'dhcpv6_stateless', and verify the ping6 available VM can ping +the other VM's v4 address in one network and v6 address in another network as well as +the v6 subnet's gateway ip. Specifically it verifies that: + +* The IPv6 addresses in mode 'dhcpv6_stateless' assigned successfully +* The VM can ping the other VM's IPv4 address in one network and IPv6 address in another + network as well as the v6 subnet's gateway ip +* All items created using create commands are able to be removed using the returned identifiers + +Post conditions +--------------- + +None + +----------------------------------------------------------------------------------------------- +Test Case 3 - IPv6 Address Assignment - Multiple Prefixes, Dual Stack, SLAAC, DHCPv6 Stateless +----------------------------------------------------------------------------------------------- + +Short name +---------- + +dovetail.tempest.ipv6_scenario.multiple_prefixes_dhcpv6_stateless + +Use case specification +---------------------- + +This test case evaluates IPv6 address assignment in ipv6_ra_mode 'dhcpv6_stateless' +and ipv6_address_mode 'dhcpv6_stateless'. +In this case, guest instance obtains IPv6 addresses from OpenStack managed radvd +using SLAAC and optional info from dnsmasq using DHCPv6 stateless. This test case then +verifies the ping6 available VM can ping the other VM's one v4 address and two v6 +addresses with different prefixes as well as the v6 subnets' gateway ips in the +same network, the reference is + +tempest.scenario.test_network_v6.TestGettingAddress.test_multi_prefix_dhcpv6_stateless + +Test preconditions +------------------ + +There should exist a public router or a public network. + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +''''''''''''''' + +* Test action 1: Create one network, storing the "id" parameter returned in the response +* Test action 2: Create one IPv4 subnet of the created network, storing the "id" + parameter returned in the response +* Test action 3: If there exists a public router, use it as the router. Otherwise, + use the public network to create a router +* Test action 4: Connect the IPv4 subnet to the router, using the stored IPv4 subnet id +* Test action 5: Create two IPv6 subnets of the network created in test action 1 in + ipv6_ra_mode 'dhcpv6_stateless' and ipv6_address_mode 'dhcpv6_stateless', + storing the "id" parameters returned in the response +* Test action 6: Connect the two IPv6 subnets to the router, using the stored IPv6 subnet ids +* Test action 7: Boot two VMs on this network, storing the "id" parameters returned in the response +* **Test assertion 1:** The vNIC of each VM gets one v4 address and two v6 addresses with + different prefixes actually assigned +* **Test assertion 2:** Each VM can ping the other's v4 private address +* **Test assertion 3:** The ping6 available VM can ping the other's v6 addresses + as well as the v6 subnets' gateway ips +* Test action 8: Delete the 2 VMs created in test action 7, using the stored ids +* Test action 9: List all VMs, verifying the ids are no longer present +* **Test assertion 4:** The two "id" parameters are not present in the VM list +* Test action 10: Delete the IPv4 subnet created in test action 2, using the stored id +* Test action 11: Delete two IPv6 subnets created in test action 5, using the stored ids +* Test action 12: List all subnets, verifying the ids are no longer present +* **Test assertion 5:** The "id" parameters of IPv4 and IPv6 are not present in the list +* Test action 13: Delete the network created in test action 1, using the stored id +* Test action 14: List all networks, verifying the id is no longer present +* **Test assertion 6:** The "id" parameter is not present in the network list + +Pass / fail criteria +''''''''''''''''''''' + +This test evaluates the ability to assign IPv6 addresses in ipv6_ra_mode 'dhcpv6_stateless' +and ipv6_address_mode 'dhcpv6_stateless', +and verify the ping6 available VM can ping the other VM's v4 address and two +v6 addresses with different prefixes as well as the v6 subnets' gateway ips in the same network. +Specifically it verifies that: + +* The different prefixes IPv6 addresses in mode 'dhcpv6_stateless' assigned successfully +* The VM can ping the other VM's IPv4 and IPv6 private addresses as well as the v6 subnets' gateway ips +* All items created using create commands are able to be removed using the returned identifiers + +Post conditions +--------------- + +None + +--------------------------------------------------------------------------------------------------------- +Test Case 4 - IPv6 Address Assignment - Dual Net, Multiple Prefixes, Dual Stack, SLAAC, DHCPv6 Stateless +--------------------------------------------------------------------------------------------------------- + +Short name +---------- + +dovetail.tempest.ipv6_scenario.dualnet_multiple_prefixes_dhcpv6_stateless + +Use case specification +---------------------- + +This test case evaluates IPv6 address assignment in ipv6_ra_mode 'dhcpv6_stateless' +and ipv6_address_mode 'dhcpv6_stateless'. +In this case, guest instance obtains IPv6 addresses from OpenStack managed radvd +using SLAAC and optional info from dnsmasq using DHCPv6 stateless. This test case then +verifies the ping6 available VM can ping the other VM's v4 address in one network +and two v6 addresses with different prefixes in another network as well as the +v6 subnets' gateway ips, the reference is + +tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_multi_prefix_dhcpv6_stateless + +Test preconditions +------------------ + +There should exist a public router or a public network. + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +''''''''''''''' + +* Test action 1: Create one network, storing the "id" parameter returned in the response +* Test action 2: Create one IPv4 subnet of the created network, storing the "id" + parameter returned in the response +* Test action 3: If there exists a public router, use it as the router. Otherwise, + use the public network to create a router +* Test action 4: Connect the IPv4 subnet to the router, using the stored IPv4 subnet id +* Test action 5: Create another network, storing the "id" parameter returned in the response +* Test action 6: Create two IPv6 subnets of network created in test action 5 in + ipv6_ra_mode 'dhcpv6_stateless' and ipv6_address_mode 'dhcpv6_stateless', + storing the "id" parameters returned in the response +* Test action 7: Connect the two IPv6 subnets to the router, using the stored IPv6 subnet ids +* Test action 8: Boot two VMs on these two networks, storing the "id" parameters returned in the response +* Test action 9: Turn on 2nd NIC of each VM for the network created in test action 5 +* **Test assertion 1:** The vNIC of each VM gets one v4 address and two v6 addresses + with different prefixes actually assigned +* **Test assertion 2:** Each VM can ping the other's v4 private address +* **Test assertion 3:** The ping6 available VM can ping the other's v6 addresses + as well as the v6 subnets' gateway ips +* Test action 10: Delete the 2 VMs created in test action 8, using the stored ids +* Test action 11: List all VMs, verifying the ids are no longer present +* **Test assertion 4:** The two "id" parameters are not present in the VM list +* Test action 12: Delete the IPv4 subnet created in test action 2, using the stored id +* Test action 13: Delete two IPv6 subnets created in test action 6, using the stored ids +* Test action 14: List all subnets, verifying the ids are no longer present +* **Test assertion 5:** The "id" parameters of IPv4 and IPv6 are not present in the list +* Test action 15: Delete the 2 networks created in test action 1 and 5, using the stored ids +* Test action 16: List all networks, verifying the ids are no longer present +* **Test assertion 6:** The two "id" parameters are not present in the network list + +Pass / fail criteria +''''''''''''''''''''' + +This test evaluates the ability to assign IPv6 addresses in ipv6_ra_mode 'dhcpv6_stateless' +and ipv6_address_mode 'dhcpv6_stateless', +and verify the ping6 available VM can ping the other VM's v4 address in one network and two +v6 addresses with different prefixes in another network as well as the v6 subnets' +gateway ips. Specifically it verifies that: + +* The IPv6 addresses in mode 'dhcpv6_stateless' assigned successfully +* The VM can ping the other VM's IPv4 and IPv6 private addresses as well as the v6 subnets' gateway ips +* All items created using create commands are able to be removed using the returned identifiers + +Post conditions +--------------- + +None + +---------------------------------------------------------- +Test Case 5 - IPv6 Address Assignment - Dual Stack, SLAAC +---------------------------------------------------------- + +Short name +---------- + +dovetail.tempest.ipv6_scenario.slaac + +Use case specification +---------------------- + +This test case evaluates IPv6 address assignment in ipv6_ra_mode 'slaac' and +ipv6_address_mode 'slaac'. +In this case, guest instance obtains IPv6 address from OpenStack managed radvd +using SLAAC. This test case then verifies the ping6 available VM can ping the other +VM's v4 and v6 addresses as well as the v6 subnet's gateway ip in the +same network, the reference is + +tempest.scenario.test_network_v6.TestGettingAddress.test_slaac_from_os + +Test preconditions +------------------ + +There should exist a public router or a public network. + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +''''''''''''''' + +* Test action 1: Create one network, storing the "id" parameter returned in the response +* Test action 2: Create one IPv4 subnet of the created network, storing the "id" + parameter returned in the response +* Test action 3: If there exists a public router, use it as the router. Otherwise, + use the public network to create a router +* Test action 4: Connect the IPv4 subnet to the router, using the stored IPv4 subnet id +* Test action 5: Create one IPv6 subnet of the network created in test action 1 in + ipv6_ra_mode 'slaac' and ipv6_address_mode 'slaac', storing the "id" parameter returned in the response +* Test action 6: Connect the IPv6 subnet to the router, using the stored IPv6 subnet id +* Test action 7: Boot two VMs on this network, storing the "id" parameters returned in the response +* **Test assertion 1:** The vNIC of each VM gets one v4 address and one v6 address actually assigned +* **Test assertion 2:** Each VM can ping the other's v4 private address +* **Test assertion 3:** The ping6 available VM can ping the other's v6 address + as well as the v6 subnet's gateway ip +* Test action 8: Delete the 2 VMs created in test action 7, using the stored ids +* Test action 9: List all VMs, verifying the ids are no longer present +* **Test assertion 4:** The two "id" parameters are not present in the VM list +* Test action 10: Delete the IPv4 subnet created in test action 2, using the stored id +* Test action 11: Delete the IPv6 subnet created in test action 5, using the stored id +* Test action 12: List all subnets, verifying the ids are no longer present +* **Test assertion 5:** The "id" parameters of IPv4 and IPv6 are not present in the list +* Test action 13: Delete the network created in test action 1, using the stored id +* Test action 14: List all networks, verifying the id is no longer present +* **Test assertion 6:** The "id" parameter is not present in the network list + +Pass / fail criteria +''''''''''''''''''''' + +This test evaluates the ability to assign IPv6 addresses in ipv6_ra_mode 'slaac' +and ipv6_address_mode 'slaac', +and verify the ping6 available VM can ping the other VM's v4 and v6 addresses as well as +the v6 subnet's gateway ip in the same network. Specifically it verifies that: + +* The IPv6 addresses in mode 'slaac' assigned successfully +* The VM can ping the other VM's IPv4 and IPv6 private addresses as well as the v6 subnet's gateway ip +* All items created using create commands are able to be removed using the returned identifiers + +Post conditions +--------------- + +None + +-------------------------------------------------------------------- +Test Case 6 - IPv6 Address Assignment - Dual Net, Dual Stack, SLAAC +-------------------------------------------------------------------- + +Short name +---------- + +dovetail.tempest.ipv6_scenario.dualnet_slaac + +Use case specification +---------------------- + +This test case evaluates IPv6 address assignment in ipv6_ra_mode 'slaac' and +ipv6_address_mode 'slaac'. +In this case, guest instance obtains IPv6 address from OpenStack managed radvd +using SLAAC. This test case then verifies the ping6 available VM can ping the other +VM's v4 address in one network and v6 address in another network as well as the +v6 subnet's gateway ip, the reference is + +tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_slaac_from_os + +Test preconditions +------------------ + +There should exist a public router or a public network. + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +''''''''''''''' + +* Test action 1: Create one network, storing the "id" parameter returned in the response +* Test action 2: Create one IPv4 subnet of the created network, storing the "id" + parameter returned in the response +* Test action 3: If there exists a public router, use it as the router. Otherwise, + use the public network to create a router +* Test action 4: Connect the IPv4 subnet to the router, using the stored IPv4 subnet id +* Test action 5: Create another network, storing the "id" parameter returned in the response +* Test action 6: Create one IPv6 subnet of network created in test action 5 in + ipv6_ra_mode 'slaac' and ipv6_address_mode 'slaac', storing the "id" parameter returned in the response +* Test action 7: Connect the IPv6 subnet to the router, using the stored IPv6 subnet id +* Test action 8: Boot two VMs on these two networks, storing the "id" parameters returned in the response +* Test action 9: Turn on 2nd NIC of each VM for the network created in test action 5 +* **Test assertion 1:** The 1st vNIC of each VM gets one v4 address assigned and + the 2nd vNIC of each VM gets one v6 address actually assigned +* **Test assertion 2:** Each VM can ping the other's v4 private address +* **Test assertion 3:** The ping6 available VM can ping the other's v6 address + as well as the v6 subnet's gateway ip +* Test action 10: Delete the 2 VMs created in test action 8, using the stored ids +* Test action 11: List all VMs, verifying the ids are no longer present +* **Test assertion 4:** The two "id" parameters are not present in the VM list +* Test action 12: Delete the IPv4 subnet created in test action 2, using the stored id +* Test action 13: Delete the IPv6 subnet created in test action 6, using the stored id +* Test action 14: List all subnets, verifying the ids are no longer present +* **Test assertion 5:** The "id" parameters of IPv4 and IPv6 are not present in the list +* Test action 15: Delete the 2 networks created in test action 1 and 5, using the stored ids +* Test action 16: List all networks, verifying the ids are no longer present +* **Test assertion 6:** The two "id" parameters are not present in the network list + +Pass / fail criteria +''''''''''''''''''''' + +This test evaluates the ability to assign IPv6 addresses in ipv6_ra_mode 'slaac' +and ipv6_address_mode 'slaac', +and verify the ping6 available VM can ping the other VM's v4 address in one network and +v6 address in another network as well as the v6 subnet's gateway ip. Specifically it verifies that: + +* The IPv6 addresses in mode 'slaac' assigned successfully +* The VM can ping the other VM's IPv4 address in one network and IPv6 address + in another network as well as the v6 subnet's gateway ip +* All items created using create commands are able to be removed using the returned identifiers + +Post conditions +--------------- + +None + +----------------------------------------------------------------------------- +Test Case 7 - IPv6 Address Assignment - Multiple Prefixes, Dual Stack, SLAAC +----------------------------------------------------------------------------- + +Short name +---------- + +dovetail.tempest.ipv6_scenario.multiple_prefixes_slaac + +Use case specification +---------------------- + +This test case evaluates IPv6 address assignment in ipv6_ra_mode 'slaac' and +ipv6_address_mode 'slaac'. +In this case, guest instance obtains IPv6 addresses from OpenStack managed radvd +using SLAAC. This test case then verifies the ping6 available VM can ping the other +VM's one v4 address and two v6 addresses with different prefixes as well as the v6 +subnets' gateway ips in the same network, the reference is + +tempest.scenario.test_network_v6.TestGettingAddress.test_multi_prefix_slaac + +Test preconditions +------------------ + +There should exists a public router or a public network. + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +''''''''''''''' + +* Test action 1: Create one network, storing the "id" parameter returned in the response +* Test action 2: Create one IPv4 subnet of the created network, storing the "id + parameter returned in the response +* Test action 3: If there exists a public router, use it as the router. Otherwise, + use the public network to create a router +* Test action 4: Connect the IPv4 subnet to the router, using the stored IPv4 subnet id +* Test action 5: Create two IPv6 subnets of the network created in test action 1 in + ipv6_ra_mode 'slaac' and ipv6_address_mode 'slaac', storing the "id" parameters returned in the response +* Test action 6: Connect the two IPv6 subnets to the router, using the stored IPv6 subnet ids +* Test action 7: Boot two VMs on this network, storing the "id" parameters returned in the response +* **Test assertion 1:** The vNIC of each VM gets one v4 address and two v6 addresses with + different prefixes actually assigned +* **Test assertion 2:** Each VM can ping the other's v4 private address +* **Test assertion 3:** The ping6 available VM can ping the other's v6 addresses + as well as the v6 subnets' gateway ips +* Test action 8: Delete the 2 VMs created in test action 7, using the stored ids +* Test action 9: List all VMs, verifying the ids are no longer present +* **Test assertion 4:** The two "id" parameters are not present in the VM list +* Test action 10: Delete the IPv4 subnet created in test action 2, using the stored id +* Test action 11: Delete two IPv6 subnets created in test action 5, using the stored ids +* Test action 12: List all subnets, verifying the ids are no longer present +* **Test assertion 5:** The "id" parameters of IPv4 and IPv6 are not present in the list +* Test action 13: Delete the network created in test action 1, using the stored id +* Test action 14: List all networks, verifying the id is no longer present +* **Test assertion 6:** The "id" parameter is not present in the network list + +Pass / fail criteria +''''''''''''''''''''' + +This test evaluates the ability to assign IPv6 addresses in ipv6_ra_mode 'slaac' +and ipv6_address_mode 'slaac', +and verify the ping6 available VM can ping the other VM's v4 address and two +v6 addresses with different prefixes as well as the v6 subnets' gateway ips in the same network. +Specifically it verifies that: + +* The different prefixes IPv6 addresses in mode 'slaac' assigned successfully +* The VM can ping the other VM's IPv4 and IPv6 private addresses as well as the v6 subnets' gateway ips +* All items created using create commands are able to be removed using the returned identifiers + +Post conditions +--------------- + +None + +--------------------------------------------------------------------------------------- +Test Case 8 - IPv6 Address Assignment - Dual Net, Dual Stack, Multiple Prefixes, SLAAC +--------------------------------------------------------------------------------------- + +Short name +---------- + +dovetail.tempest.ipv6_scenario.dualnet_multiple_prefixes_slaac + +Use case specification +---------------------- + +This test case evaluates IPv6 address assignment in ipv6_ra_mode 'slaac' and +ipv6_address_mode 'slaac'. +In this case, guest instance obtains IPv6 addresses from OpenStack managed radvd +using SLAAC. This test case then verifies the ping6 available VM can ping the other +VM's v4 address in one network and two v6 addresses with different prefixes in another +network as well as the v6 subnets' gateway ips, the reference is + +tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_multi_prefix_slaac + +Test preconditions +------------------ + +There should exist a public router or a public network. + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +''''''''''''''' + +* Test action 1: Create one network, storing the "id" parameter returned in the response +* Test action 2: Create one IPv4 subnet of the created network, storing the "id" + parameter returned in the response +* Test action 3: If there exists a public router, use it as the router. Otherwise, + use the public network to create a router +* Test action 4: Connect the IPv4 subnet to the router, using the stored IPv4 subnet id +* Test action 5: Create another network, storing the "id" parameter returned in the response +* Test action 6: Create two IPv6 subnets of network created in test action 5 in + ipv6_ra_mode 'slaac' and ipv6_address_mode 'slaac', storing the "id" parameters returned in the response +* Test action 7: Connect the two IPv6 subnets to the router, using the stored IPv6 subnet ids +* Test action 8: Boot two VMs on these two networks, storing the "id" parameters returned in the response +* Test action 9: Turn on 2nd NIC of each VM for the network created in test action 5 +* **Test assertion 1:** The vNIC of each VM gets one v4 address and two v6 addresses + with different prefixes actually assigned +* **Test assertion 2:** Each VM can ping the other's v4 private address +* **Test assertion 3:** The ping6 available VM can ping the other's v6 addresses + as well as the v6 subnets' gateway ips +* Test action 10: Delete the 2 VMs created in test action 8, using the stored ids +* Test action 11: List all VMs, verifying the ids are no longer present +* **Test assertion 4:** The two "id" parameters are not present in the VM list +* Test action 12: Delete the IPv4 subnet created in test action 2, using the stored id +* Test action 13: Delete two IPv6 subnets created in test action 6, using the stored ids +* Test action 14: List all subnets, verifying the ids are no longer present +* **Test assertion 5:** The "id" parameters of IPv4 and IPv6 are not present in the list +* Test action 15: Delete the 2 networks created in test action 1 and 5, using the stored ids +* Test action 16: List all networks, verifying the ids are no longer present +* **Test assertion 6:** The two "id" parameters are not present in the network list + +Pass / fail criteria +''''''''''''''''''''' + +This test evaluates the ability to assign IPv6 addresses in ipv6_ra_mode 'slaac' +and ipv6_address_mode 'slaac', +and verify the ping6 available VM can ping the other VM's v4 address in one network and two +v6 addresses with different prefixes in another network as well as the v6 subnets' gateway ips. +Specifically it verifies that: + +* The IPv6 addresses in mode 'slaac' assigned successfully +* The VM can ping the other VM's IPv4 and IPv6 private addresses as well as the v6 subnets' gateway ips +* All items created using create commands are able to be removed using the returned identifiers + +Post conditions +--------------- + +None + + + diff --git a/docs/testing/user/testspecification/multiplenodes/index.rst b/docs/testing/user/testspecification/tempest_multi_node_scheduling/index.rst index 4b4859a9..92c7e856 100644 --- a/docs/testing/user/testspecification/multiplenodes/index.rst +++ b/docs/testing/user/testspecification/tempest_multi_node_scheduling/index.rst @@ -53,12 +53,13 @@ on multiple nodes. Each test case is able to run independently, i.e. irrelevant 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.tc005 of +All these test cases are included in the test case dovetail.tempest.multi_node_scheduling of OVP test suite. Test Descriptions ================= +---------------------- API Used and Reference ---------------------- diff --git a/docs/testing/user/testspecification/dynamicnetwork/index.rst b/docs/testing/user/testspecification/tempest_network/network_scenario.rst index a25e4f66..6c172474 100644 --- a/docs/testing/user/testspecification/dynamicnetwork/index.rst +++ b/docs/testing/user/testspecification/tempest_network/network_scenario.rst @@ -2,9 +2,9 @@ .. http://creativecommons.org/licenses/by/4.0 .. (c) Huawei Technologies Co.,Ltd -===================================================== -Dynamic Network Runtime Operations test specification -===================================================== +=========================================== +Tempest Network Scenario test specification +=========================================== .. toctree:: :maxdepth: 2 @@ -12,7 +12,7 @@ Dynamic Network Runtime Operations test specification Scope ===== -The dynamic network runtime operations test area evaluates the ability of the +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 @@ -58,12 +58,13 @@ 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.tc003 of +All these test cases are included in the test case dovetail.tempest.network_scenario of OVP test suite. Test Descriptions ================= +---------------------- API Used and Reference ---------------------- diff --git a/docs/testing/user/testspecification/securitygroup/index.rst b/docs/testing/user/testspecification/tempest_network_security/index.rst index 61aa1c4b..2a785289 100644 --- a/docs/testing/user/testspecification/securitygroup/index.rst +++ b/docs/testing/user/testspecification/tempest_network_security/index.rst @@ -53,12 +53,13 @@ port security. 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.tc002 of +All these test cases are included in the test case dovetail.tempest.network_security of OVP test suite. Test Descriptions ================= +---------------------- API Used and Reference ---------------------- diff --git a/docs/testing/user/testspecification/tempest_osinterop/index.rst b/docs/testing/user/testspecification/tempest_osinterop/index.rst new file mode 100644 index 00000000..6773275e --- /dev/null +++ b/docs/testing/user/testspecification/tempest_osinterop/index.rst @@ -0,0 +1,38 @@ +.. 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 and others + +============================================= +OpenStack Interoperability test specification +============================================= + +The test cases documented here are the API test cases in the OpenStack +Interop guideline 2017.09 as implemented by the RefStack client. + +References +================ + +- OpenStack Governance/Interop + + - https://wiki.openstack.org/wiki/Governance/InteropWG + +- OpenStack Interoperability guidelines (version 2017.09) + + - https://github.com/openstack/interop/blob/master/2017.09.json + +- Refstack client + + - https://github.com/openstack/refstack-client + + +All OpenStack interop test cases addressed in OVP are covered in the +following test specification documents. + +.. toctree:: + :maxdepth: 1 + + tempest_osinterop_compute.rst + tempest_osinterop_identity.rst + tempest_osinterop_image.rst + tempest_osinterop_network.rst + tempest_osinterop_volume.rst diff --git a/docs/testing/user/testspecification/vimoperationscompute/index.rst b/docs/testing/user/testspecification/tempest_osinterop/tempest_osinterop_compute.rst index 64f4356b..601d1054 100644 --- a/docs/testing/user/testspecification/vimoperationscompute/index.rst +++ b/docs/testing/user/testspecification/tempest_osinterop/tempest_osinterop_compute.rst @@ -6,15 +6,12 @@ VIM compute operations test specification ========================================= -.. toctree:: - :maxdepth: 2 - Scope ===== The VIM compute operations test area evaluates the ability of the system under test to support VIM compute operations. The test cases documented here are the -compute API test cases in the OpenStack Interop guideline 2016.8 as implemented +compute API test cases in the OpenStack Interop guideline 2017.09 as implemented by the RefStack client. These test cases will evaluate basic OpenStack (as a VIM) compute operations, including: @@ -25,21 +22,6 @@ compute operations, including: - Basic server operations - Volume management operations -References -================ - -- OpenStack Governance/Interop - - - https://wiki.openstack.org/wiki/Governance/InteropWG - -- OpenStack Interoperability guidelines (version 2016.08) - - - https://github.com/openstack/interop/blob/master/2016.08.json - -- Refstack client - - - https://github.com/openstack/refstack-client - Definitions and abbreviations ============================= @@ -68,12 +50,13 @@ the same state as before the test. For brevity, the test cases in this test area are summarized together based on the operations they are testing. -All these test cases are included in the test case dovetail.osinterop.tc001 of +All these test cases are included in the test case dovetail.tempest.osinterop of OVP test suite. Test Descriptions ================= +---------------------- API Used and Reference ---------------------- @@ -392,7 +375,6 @@ tempest.api.compute.servers.test_list_server_filters.ListServerFiltersTestJSON.t tempest.api.compute.servers.test_list_server_filters.ListServerFiltersTestJSON.test_list_servers_filtered_by_name_wildcard tempest.api.compute.servers.test_list_servers_negative.ListServersNegativeTestJSON.test_list_servers_by_changes_since_future_date tempest.api.compute.servers.test_list_servers_negative.ListServersNegativeTestJSON.test_list_servers_by_changes_since_invalid_date -tempest.api.compute.servers.test_list_servers_negative.ListServersNegativeTestJSON.test_list_servers_by_limits tempest.api.compute.servers.test_list_servers_negative.ListServersNegativeTestJSON.test_list_servers_by_limits_greater_than_actual_count tempest.api.compute.servers.test_list_servers_negative.ListServersNegativeTestJSON.test_list_servers_by_limits_pass_negative_value tempest.api.compute.servers.test_list_servers_negative.ListServersNegativeTestJSON.test_list_servers_by_limits_pass_string @@ -426,6 +408,7 @@ tempest.api.compute.servers.test_create_server.ServersTestJSON.test_verify_creat tempest.api.compute.servers.test_create_server.ServersTestJSON.test_verify_server_details tempest.api.compute.servers.test_create_server.ServersTestManualDisk.test_verify_created_server_vcpus tempest.api.compute.servers.test_create_server.ServersTestManualDisk.test_verify_server_details +tempest.api.compute.servers.test_delete_server.DeleteServersTestJSON.test_delete_active_server Test preconditions ------------------ @@ -503,91 +486,91 @@ Test execution * **Test assertion 31:** Verify the filtered server list is empty * Test action 33: List all existent servers and filter the server list by a invalid change-since date format * **Test assertion 32:** Verify a bad request error is returned in the response -* Test action 34: List all existent servers and filter the server list by display limit '1' -* **Test assertion 33:** Verify the length of filtered server list is 1 -* Test action 35: List all existent servers and filter the server list by a +* Test action 34: List all existent servers and filter the server list by a display limit value greater than the length of the server list -* **Test assertion 34:** Verify the length of filtered server list equals to the length of server list -* Test action 36: List all existent servers and filter the server list by display limit '-1' +* **Test assertion 33:** Verify the length of filtered server list equals to the length of server list +* Test action 35: List all existent servers and filter the server list by display limit '-1' +* **Test assertion 34:** Verify a bad request error is returned in the response +* Test action 36: List all existent servers and filter the server list by a string type limit value 'testing' * **Test assertion 35:** Verify a bad request error is returned in the response -* Test action 37: List all existent servers and filter the server list by a string type limit value 'testing' -* **Test assertion 36:** Verify a bad request error is returned in the response -* Test action 38: List all existent servers and filter the server list by a nonexistent flavor +* Test action 37: List all existent servers and filter the server list by a nonexistent flavor +* **Test assertion 36:** Verify the filtered server list is empty +* Test action 38: List all existent servers and filter the server list by a nonexistent image * **Test assertion 37:** Verify the filtered server list is empty -* Test action 39: List all existent servers and filter the server list by a nonexistent image +* Test action 39: List all existent servers and filter the server list by a nonexistent server name * **Test assertion 38:** Verify the filtered server list is empty -* Test action 40: List all existent servers and filter the server list by a nonexistent server name -* **Test assertion 39:** Verify the filtered server list is empty -* Test action 41: List all existent servers in detail and search the server list for a deleted server -* **Test assertion 40:** Verify the deleted server is not in the server list -* Test action 42: List all existent servers and filter the server list by a nonexistent server status -* **Test assertion 41:** Verify the filtered server list is empty -* Test action 43: List all existent servers in detail -* **Test assertion 42:** Verify a provided deleted server's id is not in the server list -* Test action 44: Lock a provided server VM10 and retrieve the server's status -* **Test assertion 43:** Verify VM10 is in 'ACTIVE' status -* Test action 45: Stop VM10 -* **Test assertion 44:** Verify stop VM10 failed -* Test action 46: Unlock VM10 and stop VM10 again -* **Test assertion 45:** Verify VM10 is stopped and in 'SHUTOFF' status -* Test action 47: Start VM10 -* **Test assertion 46:** Verify VM10 is in 'ACTIVE' status -* Test action 48: Delete metadata item 'key1' from a provided server -* **Test assertion 47:** Verify the metadata item is removed -* Test action 49: Get metadata item 'key2' from a provided server -* **Test assertion 48:** Verify the metadata item is correct -* Test action 50: List all metadata key/value pair for a provided server -* **Test assertion 49:** Verify all metadata are retrieved correctly -* Test action 51: Set metadata {'meta2': 'data2', 'meta3': 'data3'} for a provided server -* **Test assertion 50:** Verify server's metadata are replaced correctly -* Test action 52: Set metadata item nova's value to 'alt' for a provided server -* **Test assertion 51:** Verify server's metadata are set correctly -* Test action 53: Update metadata {'key1': 'alt1', 'key3': 'value3'} for a provided server -* **Test assertion 52:** Verify server's metadata are updated correctly -* Test action 54: Create a server with empty name parameter -* **Test assertion 53:** Verify create server failed -* Test action 55: Hard reboot a provided server -* **Test assertion 54:** Verify server is rebooted successfully -* Test action 56: Soft reboot a nonexistent server -* **Test assertion 55:** Verify reboot failed, an error is returned in the response -* Test action 57: Rebuild a provided server with new image, new server name and metadata -* **Test assertion 56:** Verify server is rebuilt successfully, server image, name and metadata are correct -* Test action 58: Create a server VM11 -* Test action 59: Delete VM11 and wait for VM11 to reach termination -* Test action 60: Rebuild VM11 with another image +* Test action 40: List all existent servers in detail and search the server list for a deleted server +* **Test assertion 39:** Verify the deleted server is not in the server list +* Test action 41: List all existent servers and filter the server list by a nonexistent server status +* **Test assertion 40:** Verify the filtered server list is empty +* Test action 42: List all existent servers in detail +* **Test assertion 41:** Verify a provided deleted server's id is not in the server list +* Test action 43: Lock a provided server VM10 and retrieve the server's status +* **Test assertion 42:** Verify VM10 is in 'ACTIVE' status +* Test action 44: Stop VM10 +* **Test assertion 43:** Verify stop VM10 failed +* Test action 45: Unlock VM10 and stop VM10 again +* **Test assertion 44:** Verify VM10 is stopped and in 'SHUTOFF' status +* Test action 46: Start VM10 +* **Test assertion 45:** Verify VM10 is in 'ACTIVE' status +* Test action 47: Delete metadata item 'key1' from a provided server +* **Test assertion 46:** Verify the metadata item is removed +* Test action 48: Get metadata item 'key2' from a provided server +* **Test assertion 47:** Verify the metadata item is correct +* Test action 49: List all metadata key/value pair for a provided server +* **Test assertion 48:** Verify all metadata are retrieved correctly +* Test action 50: Set metadata {'meta2': 'data2', 'meta3': 'data3'} for a provided server +* **Test assertion 49:** Verify server's metadata are replaced correctly +* Test action 51: Set metadata item nova's value to 'alt' for a provided server +* **Test assertion 50:** Verify server's metadata are set correctly +* Test action 52: Update metadata {'key1': 'alt1', 'key3': 'value3'} for a provided server +* **Test assertion 51:** Verify server's metadata are updated correctly +* Test action 53: Create a server with empty name parameter +* **Test assertion 52:** Verify create server failed +* Test action 54: Hard reboot a provided server +* **Test assertion 53:** Verify server is rebooted successfully +* Test action 55: Soft reboot a nonexistent server +* **Test assertion 54:** Verify reboot failed, an error is returned in the response +* Test action 56: Rebuild a provided server with new image, new server name and metadata +* **Test assertion 55:** Verify server is rebuilt successfully, server image, name and metadata are correct +* Test action 57: Create a server VM11 +* Test action 58: Delete VM11 and wait for VM11 to reach termination +* Test action 59: Rebuild VM11 with another image +* **Test assertion 56:** Verify rebuild server failed, an error is returned in the response +* Test action 60: Rebuild a nonexistent server * **Test assertion 57:** Verify rebuild server failed, an error is returned in the response -* Test action 61: Rebuild a nonexistent server -* **Test assertion 58:** Verify rebuild server failed, an error is returned in the response -* Test action 62: Stop a provided server -* **Test assertion 59:** Verify server reaches 'SHUTOFF' status -* Test action 63: Start the stopped server -* **Test assertion 60:** Verify server reaches 'ACTIVE' status -* Test action 64: Stop a provided server -* **Test assertion 61:** Verify stop server failed, an error is returned in the response -* Test action 65: Create a server VM12 and wait it to reach 'ACTIVE' status -* Test action 66: Update VM12's IPv4 and IPv6 access addresses -* **Test assertion 62:** Verify VM12's access addresses have been updated correctly -* Test action 67: Create a server VM13 and wait it to reach 'ACTIVE' status -* Test action 68: Update VM13's server name with non-ASCII characters '\u00CD\u00F1st\u00E1\u00F1c\u00E9' -* **Test assertion 63:** Verify VM13's server name has been updated correctly -* Test action 69: Update the server name of a nonexistent server -* **Test assertion 64:** Verify update server name failed, an 'object not found' error is returned in the response -* Test action 70: Update a provided server's name with a 256-character long name -* **Test assertion 65:** Verify update server name failed, a bad request is returned in the response -* Test action 71: Update a provided server's server name with an empty string -* **Test assertion 66:** Verify update server name failed, a bad request error is returned in the response -* Test action 72: Get the number of vcpus of a provided server -* Test action 73: Get the number of vcpus stated by the server's flavor -* **Test assertion 67:** Verify that the number of vcpus reported by the server +* Test action 61: Stop a provided server +* **Test assertion 58:** Verify server reaches 'SHUTOFF' status +* Test action 62: Start the stopped server +* **Test assertion 59:** Verify server reaches 'ACTIVE' status +* Test action 63: Stop a provided server +* **Test assertion 60:** Verify stop server failed, an error is returned in the response +* Test action 64: Create a server VM12 and wait it to reach 'ACTIVE' status +* Test action 65: Update VM12's IPv4 and IPv6 access addresses +* **Test assertion 61:** Verify VM12's access addresses have been updated correctly +* Test action 66: Create a server VM13 and wait it to reach 'ACTIVE' status +* Test action 67: Update VM13's server name with non-ASCII characters '\u00CD\u00F1st\u00E1\u00F1c\u00E9' +* **Test assertion 62:** Verify VM13's server name has been updated correctly +* Test action 68: Update the server name of a nonexistent server +* **Test assertion 63:** Verify update server name failed, an 'object not found' error is returned in the response +* Test action 69: Update a provided server's name with a 256-character long name +* **Test assertion 64:** Verify update server name failed, a bad request is returned in the response +* Test action 70: Update a provided server's server name with an empty string +* **Test assertion 65:** Verify update server name failed, a bad request error is returned in the response +* Test action 71: Get the number of vcpus of a provided server +* Test action 72: Get the number of vcpus stated by the server's flavor +* **Test assertion 66:** Verify that the number of vcpus reported by the server matches the amount stated by the server's flavor -* Test action 74: Create a server VM14 -* **Test assertion 68:** Verify VM14's server attributes are set correctly -* Test action 75: Get the number of vcpus of a provided server (manual disk configuration) -* Test action 76: Get the number of vcpus stated by the server's flavor (manual disk configuration) -* **Test assertion 69:** Verify that the number of vcpus reported by the server +* Test action 73: Create a server VM14 +* **Test assertion 67:** Verify VM14's server attributes are set correctly +* Test action 74: Get the number of vcpus of a provided server (manual disk configuration) +* Test action 75: Get the number of vcpus stated by the server's flavor (manual disk configuration) +* **Test assertion 68:** Verify that the number of vcpus reported by the server matches the amount stated by the server's flavor (manual disk configuration) -* Test action 77: Create a server VM15 (manual disk configuration) -* **Test assertion 70:** Verify VM15's server attributes are set correctly (manual disk configuration) +* Test action 76: Create a server VM15 (manual disk configuration) +* **Test assertion 69:** Verify VM15's server attributes are set correctly (manual disk configuration) +* Test action 77: Create a server VM16 and then delete it when its status is 'ACTIVE' +* **Test assertion 70:** Verify VM16 is deleted successfully * Test action 78: Delete all VMs created Pass / fail criteria @@ -602,6 +585,7 @@ Specifically, the test verifies that: * Create a server with a metadata that exceeds the length limit is not allowed * Create a server with an invalid flavor, an invalid image or an invalid network UUID is not allowed * Delete a server with a server ID that exceeds the length limit or a nonexistent server ID is not allowed +* Delete a server which status is 'ACTIVE' is allowed * A provided server's host name is the same as the server name * Create a server with an invalid IPv6 access address is not allowed * A created server is in the (detailed) list of servers @@ -691,3 +675,87 @@ Post conditions --------------- N/A + +-------------------------------------------------------------------------- +Test Case 8 - List Compute service availability zones with the Compute API +-------------------------------------------------------------------------- + +Test case specification +----------------------- + +This test case evaluates the Compute API ability of listing availability zones +with a non admin user, the reference is, + +tempest.api.compute.servers.test_availability_zone.AZV2TestJSON.test_get_availability_zone_list_with_non_admin_user + +Test preconditions +------------------ + +* Compute volume extension API + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +'''''''''''''' + +* Test action 1: List availability zones with a non admin user +* **Test assertion 1:** The list is not empty + +Pass / fail criteria +'''''''''''''''''''' + +This test evaluates the functionality of listing availability zones with a non admin user. +Specifically, the test verifies that: + +* Non admin users can list availability zones. + +In order to pass this test, all test assertions listed in the test execution above need to pass. + +Post conditions +--------------- + +N/A + +------------------------------------------------- +Test Case 9 - List Flavors within the Compute API +------------------------------------------------- + +Test case specification +----------------------- + +This test case evaluates the Compute API ability of listing flavors, the reference is, + +tempest.api.compute.flavors.test_flavors.FlavorsV2TestJSON.test_list_flavors +tempest.api.compute.flavors.test_flavors.FlavorsV2TestJSON.test_list_flavors_with_detail + +Test preconditions +------------------ + +* Compute volume extension API + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +'''''''''''''' + +* Test action 1: List all flavors +* **Test assertion 1:** One given flavor is list in the all flavors' list +* Test action 2: List all flavors with details +* **Test assertion 2:** One given flavor is list in the all flavors' list + +Pass / fail criteria +'''''''''''''''''''' + +This test evaluates the functionality of listing flavors within the Compute API. +Specifically, the test verifies that: + +* Can list flavors with/without details within the Compute API. + +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/vimoperationsidentity/index.rst b/docs/testing/user/testspecification/tempest_osinterop/tempest_osinterop_identity.rst index 9790e75e..6c0d23b7 100644 --- a/docs/testing/user/testspecification/vimoperationsidentity/index.rst +++ b/docs/testing/user/testspecification/tempest_osinterop/tempest_osinterop_identity.rst @@ -6,9 +6,6 @@ VIM identity operations test specification ========================================== -.. toctree:: - :maxdepth: 2 - Scope ===== @@ -17,22 +14,6 @@ support VIM identity operations. The tests in this area will evaluate API discovery operations within the Identity v3 API, auth operations within the Identity API. -References -================ - -- OpenStack interoperability guidelines (version 2016.08) - - - https://github.com/openstack/interop/blob/master/2016.08.json - -- Openstack interoperability - - - https://www.openstack.org/brand/interop/ - -- OpenStack interoperability test cases excluding object storage - - - https://refstack.openstack.org/api/v1/guidelines/2016.08/tests?target=compute&type=required&alias=true&flag=false - - Definitions and abbreviations ============================= @@ -53,16 +34,16 @@ Test Area Structure The test area is structured based on VIM identity operations. Each test case is able to run independently, i.e. irrelevant of the state created by a previous test. -All these test cases are included in the test case dovetail.osinterop.tc001 of +All these test cases are included in the test case dovetail.tempest.osinterop of OVP test suite. Dependency Description ====================== The VIM identity operations test cases are a part of the OpenStack -interoperability tempest test cases. For Danube based dovetail release, the -OpenStack interoperability guidelines (version 2016.08) is adopted, which is -valid for Kilo, Liberty, Mitaka and Newton releases of Openstack. +interoperability tempest test cases. For Fraser based dovetail release, the +OpenStack interoperability guidelines (version 2017.09) is adopted, which is +valid for Mitaka, Newton, Ocata and Pike releases of Openstack. Test Descriptions ================= diff --git a/docs/testing/user/testspecification/vimoperationsimage/index.rst b/docs/testing/user/testspecification/tempest_osinterop/tempest_osinterop_image.rst index 2970207e..96a98631 100644 --- a/docs/testing/user/testspecification/vimoperationsimage/index.rst +++ b/docs/testing/user/testspecification/tempest_osinterop/tempest_osinterop_image.rst @@ -6,29 +6,15 @@ VIM image operations test specification ======================================= -.. toctree:: - :maxdepth: 2 - Scope ===== The VIM image test area evaluates the ability of the system under test to support VIM image operations. The test cases documented here are the Image API test cases -in the Openstack Interop guideline 2016.8 as implemented by the Refstack client. +in the Openstack Interop guideline 2017.09 as implemented by the Refstack client. These test cases will evaluate basic Openstack (as a VIM) image operations including image creation, image list, image update and image deletion capabilities using Glance v2 API. -References -========== - -- OpenStack Interoperability guidelines (version 2016.08) - - - https://github.com/openstack/interop/blob/master/2016.08.json - -- Refstack client - - - https://github.com/openstack/refstack-client - Definitions and abbreviations ============================= @@ -54,12 +40,13 @@ to run independently, i.e. irrelevant of the state created by a previous test. For brevity, the test cases in this test area are summarized together based on the operations they are testing. -All these test cases are included in the test case dovetail.osinterop.tc001 of +All these test cases are included in the test case dovetail.tempest.osinterop of OVP test suite. Test Descriptions ================= +---------------------- API Used and Reference ---------------------- diff --git a/docs/testing/user/testspecification/vimoperationsnetwork/index.rst b/docs/testing/user/testspecification/tempest_osinterop/tempest_osinterop_network.rst index bf929828..a21b303c 100644 --- a/docs/testing/user/testspecification/vimoperationsnetwork/index.rst +++ b/docs/testing/user/testspecification/tempest_osinterop/tempest_osinterop_network.rst @@ -6,29 +6,15 @@ VIM network operations test specification ========================================= -.. toctree:: - :maxdepth: 2 - Scope ===== The VIM network test area evaluates the ability of the system under test to support VIM network operations. The test cases documented here are the network API test cases -in the Openstack Interop guideline 2016.8 as implemented by the Refstack client. +in the Openstack Interop guideline 2017.09 as implemented by the Refstack client. These test cases will evaluate basic Openstack (as a VIM) network operations including basic CRUD operations on L2 networks, L2 network ports and security groups. -References -========== - -- OpenStack Interoperability guidelines (version 2016.08) - - - https://github.com/openstack/interop/blob/master/2016.08.json - -- Refstack client - - - https://github.com/openstack/refstack-client - Definitions and abbreviations ============================= @@ -56,12 +42,13 @@ the same state as before the test. For brevity, the test cases in this test area are summarized together based on the operations they are testing. -All these test cases are included in the test case dovetail.osinterop.tc001 of +All these test cases are included in the test case dovetail.tempest.osinterop of OVP test suite. Test Descriptions ================= +---------------------- API Used and Reference ---------------------- @@ -129,8 +116,6 @@ tempest.api.network.test_ports.PortsTestJSON.test_list_ports tempest.api.network.test_ports.PortsTestJSON.test_list_ports_fields tempest.api.network.test_ports.PortsTestJSON.test_show_port tempest.api.network.test_ports.PortsTestJSON.test_show_port_fields -tempest.api.network.test_ports.PortsTestJSON.test_update_port_with_security_group_and_extra_attributes -tempest.api.network.test_ports.PortsTestJSON.test_update_port_with_two_security_groups_and_extra_attributes Test preconditions ------------------ @@ -225,16 +210,6 @@ Test execution and mac_address info with the port's id * **Test assertion 25:** The keys returned in the response are just id and mac_address, and the values of all the keys equal to port's id and mac_address -* Test action 26: Create a network, 2 subnets (SUBNET1 and SUBNET2) and 2 security groups - (SG1 and SG2), create a port with SG1 and SUBNET1, then update the port's security group to SG2 - and its subnet_id to SUBNET2 -* **Test assertion 26:** The port's subnet_id equals to SUBNET2's id and its security_group_ids - equals to SG2's id -* Test action 27: Create a network, 2 subnets (SUBNET1 and SUBNET2) and 3 security groups - (SG1, SG2 and SG3), create a port with SG1 and SUBNET1, then update the port's security group to - SG2 and SG3 and its subnet_id to SUBNET2 -* **Test assertion 27:** The port's subnet_id equal to SUBNET2's id and its security_group_ids - equals to the ids of SG2 and SG3 Pass / fail criteria '''''''''''''''''''' @@ -366,3 +341,47 @@ Post conditions --------------- N/A + +------------------------------- +CRUD operations on subnet pools +------------------------------- + +Test case specification +----------------------- + +tempest.api.network.test_subnetpools_extensions.SubnetPoolsTestJSON.test_create_list_show_update_delete_subnetpools + +Test preconditions +------------------ + +Neutron is available. + +Basic test flow execution description and pass/fail criteria +------------------------------------------------------------ + +Test execution +'''''''''''''' + +* Test action 1: Create a subnetpool SNP1 with a specific name and get the name from the response body +* **Test assertion 1:** The name got from the body is the same as the name used to create SNP1 +* Test action 2: Show SNP1 and get the name from the response body +* **Test assertion 2:** The name got from the body is the same as the name used to create SNP1 +* Test action 3: Update the name of SNP1 and get the new name from the response body +* **Test assertion 3:** The name got from the body is the same as the name used to update SNP1 +* Test action 4: Delete SNP1 + + +Pass / fail criteria +'''''''''''''''''''' + +These test cases evaluate the ability of Basic CRUD operations on subnetpools. +Specifically it verifies that: + +* Subnetpools can be created, updated, shown and deleted. + +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/vimoperationsvolume/index.rst b/docs/testing/user/testspecification/tempest_osinterop/tempest_osinterop_volume.rst index ce51b954..097123aa 100644 --- a/docs/testing/user/testspecification/vimoperationsvolume/index.rst +++ b/docs/testing/user/testspecification/tempest_osinterop/tempest_osinterop_volume.rst @@ -6,15 +6,12 @@ VIM volume operations test specification ========================================= -.. toctree:: - :maxdepth: 2 - Scope ===== The VIM volume operations test area evaluates the ability of the system under test to support VIM volume operations. The test cases documented here are the -volume API test cases in the OpenStack Interop guideline 2016.8 as implemented +volume API test cases in the OpenStack Interop guideline 2017.09 as implemented by the RefStack client. These test cases will evaluate basic OpenStack (as a VIM) volume operations, including: @@ -27,21 +24,6 @@ volume operations, including: - Volume metadata operations - Volume snapshot operations -References -================ - -- OpenStack Governance/Interop - - - https://wiki.openstack.org/wiki/Governance/InteropWG - -- OpenStack Interoperability guidelines (version 2016.08) - - - https://github.com/openstack/interop/blob/master/2016.08.json - -- Refstack client - - - https://github.com/openstack/refstack-client - Definitions and abbreviations ============================= @@ -69,12 +51,13 @@ the same state as before the test. For brevity, the test cases in this test area are summarized together based on the operations they are testing. -All these test cases are included in the test case dovetail.osinterop.tc001 of +All these test cases are included in the test case dovetail.tempest.osinterop of OVP test suite. Test Descriptions ================= +---------------------- API Used and Reference ---------------------- @@ -94,17 +77,14 @@ Block storage: https://developer.openstack.org/api-ref/block-storage - update snapshot - delete snapshot ------------------------------------------------------------------------- -Test Case 1 - Volume attach and detach operations with the Cinder v2 API ------------------------------------------------------------------------- +----------------------------------------------------- +Test Case 1 - Upload volumes with Cinder v2 or v3 API +----------------------------------------------------- Test case specification ----------------------- -tempest.api.volume.test_volumes_actions.VolumesV2ActionsTest.test_attach_detach_volume_to_instance -tempest.api.volume.test_volumes_actions.VolumesV2ActionsTest.test_get_volume_attachment -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_attach_volumes_with_nonexistent_volume_id -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_detach_volumes_with_invalid_volume_id +tempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_upload Test preconditions ------------------ @@ -116,30 +96,20 @@ Basic test flow execution description and pass/fail criteria Test execution '''''''''''''' -* Test action 1: Create a server VM1 -* Test action 2: Attach a provided VOL1 to VM1 -* **Test assertion 1:** Verify VOL1 is in 'in-use' status -* Test action 3: Detach VOL1 from VM1 -* **Test assertion 2:** Verify VOL1 is in 'available' status -* Test action 4: Create a server VM2 -* Test action 5: Attach a provided VOL2 to VM2 and wait for VOL2 to reach 'in-use' status -* Test action 6: Retrieve VOL2's attachment information ATTCH_INFO -* **Test assertion 3:** Verify ATTCH_INFO is correct -* Test action 7: Create a server VM3 and wait for VM3 to reach 'ACTIVE' status -* Test action 8: Attach a non-existent volume to VM3 -* **Test assertion 4:** Verify attach volume failed, a 'NOT FOUND' error is returned in the response -* Test action 9: Detach a volume from a server by using an invalid volume ID -* **Test assertion 5:** Verify detach volume failed, a 'NOT FOUND' error is returned in the response +* Test action 1: Create a volume VOL1 +* Test action 2: Convert VOL1 and upload image IMG1 to the Glance +* Test action 3: Wait until the status of IMG1 is 'ACTIVE' and VOL1 is 'available' +* Test action 4: Show the details of IMG1 +* **Test assertion 1:** The name of IMG1 shown is the same as the name used to upload it +* **Test assertion 2:** The disk_format of IMG1 is the same as the disk_format of VOL1 Pass / fail criteria '''''''''''''''''''' -This test evaluates the volume API ability of attaching a volume to a server -and detaching a volume from a server. Specifically, the test verifies that: +This test case evaluates the volume API ability of uploading images. +Specifically, the test verifies that: -* Volumes can be attached and detached from servers. -* Volume attachment information can be retrieved. -* Attach and detach a volume using an invalid volume ID is not allowed. +* The Volume can convert volumes and upload images. In order to pass this test, all test assertions listed in the test execution above need to pass. @@ -148,14 +118,14 @@ Post conditions N/A --------------------------------------------------------------------------------- -Test Case 2 - Volume service availability zone operations with the Cinder v2 API --------------------------------------------------------------------------------- +-------------------------------------------------------------------------------------- +Test Case 2 - Volume service availability zone operations with the Cinder v2 or v3 API +-------------------------------------------------------------------------------------- Test case specification ----------------------- -tempest.api.volume.test_availability_zone.AvailabilityZoneV2TestJSON.test_get_availability_zone_list +tempest.api.volume.test_availability_zone.AvailabilityZoneTestJSON.test_get_availability_zone_list Test preconditions ------------------ @@ -185,14 +155,14 @@ Post conditions N/A --------------------------------------------------------------- -Test Case 3 - Volume cloning operations with the Cinder v2 API --------------------------------------------------------------- +-------------------------------------------------------------------- +Test Case 3 - Volume cloning operations with the Cinder v2 or v3 API +-------------------------------------------------------------------- Test case specification ----------------------- -tempest.api.volume.test_volumes_get.VolumesV2GetTest.test_volume_create_get_update_delete_as_clone +tempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_as_clone Test preconditions ------------------ @@ -239,15 +209,15 @@ Post conditions N/A --------------------------------------------------------------------- -Test Case 4 - Image copy-to-volume operations with the Cinder v2 API --------------------------------------------------------------------- +-------------------------------------------------------------------------- +Test Case 4 - Image copy-to-volume operations with the Cinder v2 or v3 API +-------------------------------------------------------------------------- Test case specification ----------------------- -tempest.api.volume.test_volumes_actions.VolumesV2ActionsTest.test_volume_bootable -tempest.api.volume.test_volumes_get.VolumesV2GetTest.test_volume_create_get_update_delete_from_image +tempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_bootable +tempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete_from_image Test preconditions ------------------ @@ -299,20 +269,20 @@ Post conditions N/A ----------------------------------------------------------------------------- -Test Case 5 - Volume creation and deletion operations with the Cinder v2 API ----------------------------------------------------------------------------- +---------------------------------------------------------------------------------- +Test Case 5 - Volume creation and deletion operations with the Cinder v2 or v3 API +---------------------------------------------------------------------------------- Test case specification ----------------------- -tempest.api.volume.test_volumes_get.VolumesV2GetTest.test_volume_create_get_update_delete -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_create_volume_with_invalid_size -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_create_volume_with_nonexistent_source_volid -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_create_volume_with_nonexistent_volume_type -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_create_volume_without_passing_size -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_create_volume_with_size_negative -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_create_volume_with_size_zero +tempest.api.volume.test_volumes_get.VolumesGetTest.test_volume_create_get_update_delete +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_invalid_size +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_nonexistent_source_volid +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_nonexistent_volume_type +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_without_passing_size +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_negative +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_size_zero Test preconditions ------------------ @@ -372,14 +342,14 @@ Post conditions N/A --------------------------------------------------------------------------------- -Test Case 6 - Volume service extension listing operations with the Cinder v2 API --------------------------------------------------------------------------------- +-------------------------------------------------------------------------------------- +Test Case 6 - Volume service extension listing operations with the Cinder v2 or v3 API +-------------------------------------------------------------------------------------- Test case specification ----------------------- -tempest.api.volume.test_extensions.ExtensionsV2TestJSON.test_list_extensions +tempest.api.volume.test_extensions.ExtensionsTestJSON.test_list_extensions Test preconditions ------------------ @@ -410,16 +380,16 @@ Post conditions N/A ----------------------------------------------------------- -Test Case 7 - Volume GET operations with the Cinder v2 API ----------------------------------------------------------- +---------------------------------------------------------------- +Test Case 7 - Volume GET operations with the Cinder v2 or v3 API +---------------------------------------------------------------- Test case specification ----------------------- -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_get_invalid_volume_id -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_get_volume_without_passing_volume_id -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_volume_get_nonexistent_volume_id +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_invalid_volume_id +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_get_volume_without_passing_volume_id +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_get_nonexistent_volume_id Test preconditions ------------------ @@ -454,32 +424,32 @@ Post conditions N/A --------------------------------------------------------------- -Test Case 8 - Volume listing operations with the Cinder v2 API --------------------------------------------------------------- +-------------------------------------------------------------------- +Test Case 8 - Volume listing operations with the Cinder v2 or v3 API +-------------------------------------------------------------------- Test case specification ----------------------- -tempest.api.volume.test_volumes_list.VolumesV2ListTestJSON.test_volume_list -tempest.api.volume.test_volumes_list.VolumesV2ListTestJSON.test_volume_list_by_name -tempest.api.volume.test_volumes_list.VolumesV2ListTestJSON.test_volume_list_details_by_name -tempest.api.volume.test_volumes_list.VolumesV2ListTestJSON.test_volume_list_param_display_name_and_status -tempest.api.volume.test_volumes_list.VolumesV2ListTestJSON.test_volume_list_with_detail_param_display_name_and_status -tempest.api.volume.test_volumes_list.VolumesV2ListTestJSON.test_volume_list_with_detail_param_metadata -tempest.api.volume.test_volumes_list.VolumesV2ListTestJSON.test_volume_list_with_details -tempest.api.volume.test_volumes_list.VolumesV2ListTestJSON.test_volume_list_with_param_metadata -tempest.api.volume.test_volumes_list.VolumesV2ListTestJSON.test_volumes_list_by_availability_zone -tempest.api.volume.test_volumes_list.VolumesV2ListTestJSON.test_volumes_list_by_status -tempest.api.volume.test_volumes_list.VolumesV2ListTestJSON.test_volumes_list_details_by_availability_zone -tempest.api.volume.test_volumes_list.VolumesV2ListTestJSON.test_volumes_list_details_by_status -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_list_volumes_detail_with_invalid_status -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_list_volumes_detail_with_nonexistent_name -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_list_volumes_with_invalid_status -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_list_volumes_with_nonexistent_name -tempest.api.volume.v2.test_volumes_list.VolumesV2ListTestJSON.test_volume_list_details_pagination -tempest.api.volume.v2.test_volumes_list.VolumesV2ListTestJSON.test_volume_list_details_with_multiple_params -tempest.api.volume.v2.test_volumes_list.VolumesV2ListTestJSON.test_volume_list_pagination +tempest.api.volume.test_volumes_list.VolumesListTestJSON.test_volume_list +tempest.api.volume.test_volumes_list.VolumesListTestJSON.test_volume_list_by_name +tempest.api.volume.test_volumes_list.VolumesListTestJSON.test_volume_list_details_by_name +tempest.api.volume.test_volumes_list.VolumesListTestJSON.test_volume_list_param_display_name_and_status +tempest.api.volume.test_volumes_list.VolumesListTestJSON.test_volume_list_with_detail_param_display_name_and_status +tempest.api.volume.test_volumes_list.VolumesListTestJSON.test_volume_list_with_detail_param_metadata +tempest.api.volume.test_volumes_list.VolumesListTestJSON.test_volume_list_with_details +tempest.api.volume.test_volumes_list.VolumesListTestJSON.test_volume_list_with_param_metadata +tempest.api.volume.test_volumes_list.VolumesListTestJSON.test_volumes_list_by_availability_zone +tempest.api.volume.test_volumes_list.VolumesListTestJSON.test_volumes_list_by_status +tempest.api.volume.test_volumes_list.VolumesListTestJSON.test_volumes_list_details_by_availability_zone +tempest.api.volume.test_volumes_list.VolumesListTestJSON.test_volumes_list_details_by_status +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_list_volumes_detail_with_invalid_status +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_list_volumes_detail_with_nonexistent_name +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_list_volumes_with_invalid_status +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_list_volumes_with_nonexistent_name +tempest.api.volume.test_volumes_list.VolumesListTestJSON.test_volume_list_details_pagination +tempest.api.volume.test_volumes_list.VolumesListTestJSON.test_volume_list_details_with_multiple_params +tempest.api.volume.test_volumes_list.VolumesListTestJSON.test_volume_list_pagination Test preconditions ------------------ @@ -558,15 +528,15 @@ Post conditions N/A ---------------------------------------------------------------- -Test Case 9 - Volume metadata operations with the Cinder v2 API ---------------------------------------------------------------- +--------------------------------------------------------------------- +Test Case 9 - Volume metadata operations with the Cinder v2 or v3 API +--------------------------------------------------------------------- Test case specification ----------------------- -tempest.api.volume.test_volume_metadata.VolumesV2MetadataTest.test_crud_volume_metadata -tempest.api.volume.test_volume_metadata.VolumesV2MetadataTest.test_update_volume_metadata_item +tempest.api.volume.test_volume_metadata.VolumesMetadataTest.test_crud_volume_metadata +tempest.api.volume.test_volume_metadata.VolumesMetadataTest.test_update_show_volume_metadata_item Test preconditions ------------------ @@ -610,14 +580,14 @@ Post conditions N/A ---------------------------------------------------------------------------------- -Test Case 10 - Verification of read-only status on volumes with the Cinder v2 API ---------------------------------------------------------------------------------- +--------------------------------------------------------------------------------------- +Test Case 10 - Verification of read-only status on volumes with the Cinder v2 or v3 API +--------------------------------------------------------------------------------------- Test case specification ----------------------- -tempest.api.volume.test_volumes_actions.VolumesV2ActionsTest.test_volume_readonly_update +tempest.api.volume.test_volumes_actions.VolumesActionsTest.test_volume_readonly_update Test preconditions ------------------ @@ -650,17 +620,17 @@ Post conditions N/A -------------------------------------------------------------------- -Test Case 11 - Volume reservation operations with the Cinder v2 API -------------------------------------------------------------------- +------------------------------------------------------------------------- +Test Case 11 - Volume reservation operations with the Cinder v2 or v3 API +------------------------------------------------------------------------- Test case specification ----------------------- -tempest.api.volume.test_volumes_actions.VolumesV2ActionsTest.test_reserve_unreserve_volume -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_reserve_volume_with_negative_volume_status -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_reserve_volume_with_nonexistent_volume_id -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_unreserve_volume_with_nonexistent_volume_id +tempest.api.volume.test_volumes_actions.VolumesActionsTest.test_reserve_unreserve_volume +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_reserve_volume_with_negative_volume_status +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_reserve_volume_with_nonexistent_volume_id +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_unreserve_volume_with_nonexistent_volume_id Test preconditions ------------------ @@ -703,25 +673,25 @@ Post conditions N/A ----------------------------------------------------------------------------------- -Test Case 12 - Volume snapshot creation/deletion operations with the Cinder v2 API ----------------------------------------------------------------------------------- +---------------------------------------------------------------------------------------- +Test Case 12 - Volume snapshot creation/deletion operations with the Cinder v2 or v3 API +---------------------------------------------------------------------------------------- Test case specification ----------------------- -tempest.api.volume.test_snapshot_metadata.SnapshotV2MetadataTestJSON.test_crud_snapshot_metadata -tempest.api.volume.test_snapshot_metadata.SnapshotV2MetadataTestJSON.test_update_snapshot_metadata_item -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_create_volume_with_nonexistent_snapshot_id -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_delete_invalid_volume_id -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_delete_volume_without_passing_volume_id -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_volume_delete_nonexistent_volume_id -tempest.api.volume.test_volumes_snapshots.VolumesV2SnapshotTestJSON.test_snapshot_create_get_list_update_delete -tempest.api.volume.test_volumes_snapshots.VolumesV2SnapshotTestJSON.test_volume_from_snapshot -tempest.api.volume.test_volumes_snapshots_list.VolumesV2SnapshotListTestJSON.test_snapshots_list_details_with_params -tempest.api.volume.test_volumes_snapshots_list.VolumesV2SnapshotListTestJSON.test_snapshots_list_with_params -tempest.api.volume.test_volumes_snapshots_negative.VolumesV2SnapshotNegativeTestJSON.test_create_snapshot_with_nonexistent_volume_id -tempest.api.volume.test_volumes_snapshots_negative.VolumesV2SnapshotNegativeTestJSON.test_create_snapshot_without_passing_volume_id +tempest.api.volume.test_snapshot_metadata.SnapshotMetadataTestJSON.test_crud_snapshot_metadata +tempest.api.volume.test_snapshot_metadata.SnapshotMetadataTestJSON.test_update_show_snapshot_metadata_item +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_create_volume_with_nonexistent_snapshot_id +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_invalid_volume_id +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_delete_volume_without_passing_volume_id +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_volume_delete_nonexistent_volume_id +tempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestJSON.test_snapshot_create_get_list_update_delete +tempest.api.volume.test_volumes_snapshots.VolumesSnapshotTestJSON.test_volume_from_snapshot +tempest.api.volume.test_volumes_snapshots_list.VolumesSnapshotListTestJSON.test_snapshots_list_details_with_params +tempest.api.volume.test_volumes_snapshots_list.VolumesSnapshotListTestJSON.test_snapshots_list_with_params +tempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestJSON.test_create_snapshot_with_nonexistent_volume_id +tempest.api.volume.test_volumes_snapshots_negative.VolumesSnapshotNegativeTestJSON.test_create_snapshot_without_passing_volume_id Test preconditions ------------------ @@ -813,16 +783,16 @@ Post conditions N/A --------------------------------------------------------------- -Test Case 13 - Volume update operations with the Cinder v2 API --------------------------------------------------------------- +-------------------------------------------------------------------- +Test Case 13 - Volume update operations with the Cinder v2 or v3 API +-------------------------------------------------------------------- Test case specification ----------------------- -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_update_volume_with_empty_volume_id -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_update_volume_with_invalid_volume_id -tempest.api.volume.test_volumes_negative.VolumesV2NegativeTest.test_update_volume_with_nonexistent_volume_id +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_empty_volume_id +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_invalid_volume_id +tempest.api.volume.test_volumes_negative.VolumesNegativeTest.test_update_volume_with_nonexistent_volume_id Test preconditions ------------------ diff --git a/docs/testing/user/testspecification/machinelifecycle/index.rst b/docs/testing/user/testspecification/tempest_vm_lifecycle/index.rst index b0cc0d79..7091929a 100644 --- a/docs/testing/user/testspecification/machinelifecycle/index.rst +++ b/docs/testing/user/testspecification/tempest_vm_lifecycle/index.rst @@ -59,12 +59,13 @@ 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.tc004 of +All these test cases are included in the test case dovetail.tempest.vm_lifecycle of OVP test suite. Test Descriptions ================= +---------------------- API Used and Reference ---------------------- diff --git a/docs/testing/user/testspecification/vping/index.rst b/docs/testing/user/testspecification/vping/index.rst index 486ee842..93613365 100644 --- a/docs/testing/user/testspecification/vping/index.rst +++ b/docs/testing/user/testspecification/vping/index.rst @@ -77,7 +77,7 @@ Test Case 1 - vPing using userdata provided by nova metadata service Short name ---------- -dovetail.vping.tc001.userdata +dovetail.vping.userdata Use case specification @@ -111,15 +111,15 @@ 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 + * 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 + * 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 @@ -177,7 +177,7 @@ Test Case 2 - vPing using SSH to a floating IP Short name ---------- -dovetail.vping.tc002.ssh +dovetail.vping.ssh Use case specification @@ -212,15 +212,15 @@ 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 + * 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 + * 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 diff --git a/docs/testing/user/testspecification/vpn/index.rst b/docs/testing/user/testspecification/vpn/index.rst index 13c0cfa6..5cf92f1a 100644 --- a/docs/testing/user/testspecification/vpn/index.rst +++ b/docs/testing/user/testspecification/vpn/index.rst @@ -85,7 +85,7 @@ Test Case 1 - VPN provides connectivity between Neutron subnets Short name ---------- -dovetail.sdnvpn.tc001.subnet_connectivity +dovetail.sdnvpn.subnet_connectivity Use case specification @@ -200,7 +200,7 @@ Test Case 2 - VPNs ensure traffic separation between tenants Short Name ---------- -dovetail.sdnvpn.tc002.tenant_separation +dovetail.sdnvpn.tenant_separation Use case specification @@ -317,7 +317,7 @@ Test Case 3 - VPN provides connectivity between subnets using router association Short Name ---------- -dovetail.sdnvpn.tc004.router_association +dovetail.sdnvpn.router_association Use case specification @@ -441,7 +441,7 @@ Test Case 4 - Verify interworking of router and network associations with floati Short Name ---------- -dovetail.sdnvpn.tc008.router_association_floating_ip +dovetail.sdnvpn.router_association_floating_ip Use case specification |