From 0aa38f991cc8defd2cf46bea93f16938a3d66927 Mon Sep 17 00:00:00 2001 From: Qihui Zhao Date: Thu, 9 May 2019 11:33:57 +0800 Subject: upload test case for edge cloud Change-Id: I6c55dc0dfe14a3e9658bda86d5fc468168b37129 Signed-off-by: Qihui Zhao --- .../edge_cloud_test_case_reference.rst | 476 +++++++++++++++++++++ docs/development/requirements/index.rst | 2 +- 2 files changed, 477 insertions(+), 1 deletion(-) create mode 100644 docs/development/requirements/edge_cloud_test_case_reference.rst (limited to 'docs') diff --git a/docs/development/requirements/edge_cloud_test_case_reference.rst b/docs/development/requirements/edge_cloud_test_case_reference.rst new file mode 100644 index 0000000..62af5d4 --- /dev/null +++ b/docs/development/requirements/edge_cloud_test_case_reference.rst @@ -0,0 +1,476 @@ +.. _opnfv-installation: + +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. SPDX-License-Identifier: CC-BY-4.0 +.. (c) Qihui Zhao China Mobile and other contributors + +==================================== +**Edge Cloud Test Case Reference** +==================================== + + +**Introduction** +================= + +This is a document for limited edge cloud test cases. It can be used as reference for + edge cloud testing. + +Cases cover basic functions of virtualization layer, basic functions of OpenStack, + reliability, management of multiple OpenStack, and performance. + + +**Basic Functions of Virtualization Layer** +============================================ + +**Test case #1: Resource isolation** + +**Description**: Resources used by VMs running on the same server should be seperated and + isolated. + +**Preconditions**:none + +**Steps**: + +1. VM1 and VM2 running on one server + +2. Monitoring CPU and memory usage rate of these two VMs + +3. Login to VM2, add pressure to VM2's memory + +4. Check CPU and memory usage rate of VM1 and VM2 + +**Expected outcome**: Usage rate of VM2's memory increase rapidly after adding pressure + while that of VM1 stays steady + +---------------------------------------- + +**Test case #2: Support control & compute mixed deployment on one server** + +**Description**: Edge OpenStack supports control services and compute services to be + deployed on the same server + +**Preconditions**: +An OpenStack system with all-in-one node has been setup, where openstack control + processes and compute processes running on the same node + +**Steps**: + +1. Check the processes on an all-in-one node + +2. Create a VM on this node + +**Expected outcome**: + +1. control processes and compute processes such as nova-compute can be found on + all-in-one node + +2. successfully create VM + +---------------------------------------- + +**Test case #3: Local LVM backend** + +**Description**: Virtualization layer uses local LVM as the storage backend + +**Preconditions**: An OpenStack system with LVM as storage backend has been setup + +**Steps**: + +1. Check the usable storage capacity + +2. Create a volume of 10GB and attach to a VM + +3. Check the usable storage capacity + +**Expected outcome**: +The difference of local avaliable storage between step 1 and step 3 is 10GB + + +**Functions of OpenStack as VIM** +================================== + +**Test case #4: Cold migration** + +**Description**: OpenStack support cold migration of VM + +**Preconditions**: OpenStack system with at least two physical server has been setup + +**Steps**: + +1. Start with a VM running on one node + +2. Check the location of this VM, VM ID, IP, and internal data + +3. Cold migrate this VM + +4. Check the location of this VM, VM ID, IP, and internal data + +**Expected outcome**: + +1. Notifications like "Succeffuly migrated " can be found + +2. After step 4, except for location of this VM, the rest information stays the same as + those in step 2 + +---------------------------------------- + +**Test case #5: Check VIM resouce occupation** + +**Description**: Check the resource occupation of hypervisor or OpenStack control services + +**Preconditions**: An OpenStack system with control services and compute services deployed + on the same server has been setup (control services could be deployed in HA mode, only + total usage of control services/hypervisor would be check in this case) + +**Steps**: + +1. Choose an environment using all-in-one deployment + +2. Check the total CPU number of the system + +3. On webpage or using "top" command to check the CPU resources used by hypervisor or + OpenStack control services + +4. Create VMs using all the rest CPUs + +**Expected outcome**: + +1. VMs created successfully + +2. CPU number of HostOS&OVS/DPDK (which could be treated as hypervisor) + CPU number + of control services + CPU number of VMs = total CPU number + +**Reliability of System** +========================== + +**Test case #6: Cluster reliability** + +**Description**: Verify VIM reliability and reliability of VMs on an server in which + the OpenStack control services and compute service has been deployed + +**Preconditions**: + +1. Edge OpenStack has been setup, there are at least two servers in this system + +2. VIM is deployed with control services and compute services on the same node and at + least 2 HA for control services (on different nodes) + +3. System is working normally + +4. At least one VM is running on each node in this system + +**Steps**: + +1. check the primary VIM node (an all-in-one node) and processes running on it; make + sure there is at least one VM running on it, and VMs running on other node + +2. keep ping VMs on other nodes except VMs on primary VIM node + +3. Power off this server of primary VIM node + +4. Create VM on other node to check whether the function of VIM has been influenced + by the stop of primary VIM node + +5. Check whether the VM used to be on primary VIM node has been migrated to other nodes + +6. Check the corresponding alarm within this system + +**Expected outcome**: + +1. After step 3, communication to VMs which are not on primary VIM node (in step 2) + is not interrupt + +2. VM can be created successfully in step 4 + +3. In step 5, VM used to be on primary VIM node has been migrated to other nodes + +4. In step 6, alarms related to server down can be found within the system + +---------------------------------------- + +**Test case #7: Test VM Operations on isolated edge cloud** + +**Description**: If the network between center of edge and edge broke, the edge should + be able to provide basic VM operation functions (Reliability of multi-cloud system + under unreliable network) + +**Preconditions**: + +1. A multi-cloud system has been setup and operate normally + +2. the network between the "center of edge" and edge is controllable + +**Steps**: + +1. Before edge cloud isolated: Launch VM, Vm Launch success. + +2. VM image is cached, hit shows 0: glance-cache-manage -H ${subcloud_floating_ip} + list-cached. + +3. Cut off network connection between center of edge and edge cloud + +4. Launch VM with cached image, VM launch success. + +5. VM rebuild + +6. VM live migration + +7. VM cold migration + +8. VM evacuation + +9. Vm delete + +**Expected outcome**: All Test Steps are passed. + + +**Management of Multiple OpenStack** +============================================= + +**Test case #8: "Single Sign on" in multiple cloud environment** + +**Description**:Maintainers/Users can login to central cloud/large edge cloud, and + can jump to edge cloud without entering user name and password again + +**Preconditions**: + +1. A multi-cloud system has been established, with a cloud play as "central" or the + multi-cloud management platform play as the "central" + +2. The network between the "central" and edge are available + +**Steps**: + +1. Login to central cloud/large edge cloud with user name and password + +2. Jump to related medium/small edge cloud withoud reentering username and password + +**Expected outcome**: Jump from central/large edge to medium/small edge succefully + +---------------------------------------- + +**Test case #9: Manage a newly established edge cloud** + +**Description**: The central cloud or large edge cloud or multi-cloud management + platform should supports the management of newly created edge sites (the edge site + has already exist in this case) + +**Preconditions**: + +1. A multi-cloud system has been established, with a cloud play as "central" or + the multi-cloud management platform play as the "central" + +2. And edge cloud has already exist but not managed by central edge cloud + +3. The network between the "central" and edge are available + +**Steps**: + +1. Log into "central" cloud or multi-cloud platform using admin account and switch + to "add cloud environment" related page (using CLI is also ok) + +2. Filling the accessing interface/URL information of a newly created edge VIM + +**Expected outcome**: + +1. The accessing interface/URL can be added to the "central" cloud or multi-cloud + management platform; + +2. Using the interface/URL can jump to the newly created edge VIM correctly + +3. We can list the managed edge VIMs + +---------------------------------------- + +**Test case #10: Removing a managed edge cloud** + +**Description**: The central cloud or large edge cloud or multi-cloud management + platform should supports to remove an edge VIM from "managed" list + +**Preconditions**: + +1. A multi-cloud system has been established, with a cloud play as "central" or the + multi-cloud management platform play as the "central" + +2. And edge cloud has already exist and has managed by central edge cloud + +3. The network between the "central" and edge are available + +**Steps**: + +1. Log into "central" cloud or multi-cloud platform using admin account and switch + to "managed cloud list" related page (using CLI is also ok) + +2. remove the edge cloud from the center of edge + +**Expected outcome**: The edge cloud has been remove from the managed cloud list, + and cannot reached from the center of edge + +---------------------------------------- + +**Test case #11: Provision a new edge hardware from the central cloud** + +**Description**:There is remote hardware that is ready to host edge software. That + hardware must be provisioned from the central edge in an automated way + +**Preconditions**: + +1. A multi-cloud system has been established, with a cloud play as "central" or the + multi-cloud management platform play as the "central" + +2. The central node has a DHCP and HTTP server which is capable of booting thorugh PXE + +3. An edge node exists + +4. The network between the "central" and edge are available (L2? L3?) --> Not sure + how this would work if the new node and the server are not in the same L2 network + (which is the general case) + +**Steps**: + +1. Power on the node remotely (e.g. through BMC) and configures PXE booting in BIOS + +2. Verify that the DHCP server detects the message and the PXE boot starts + +3. Check after a reasonable time that the node is booted + +**Expected outcome**: + +1. Node powers on and starts PXE boot + +2. PXE boot packages reach the central cloud + +3. Node downloads the image and dumps it into its hard drive + +4. We can access the node (e.g. ssh) + +---------------------------------------- + +**Test case #12: Display multi-VIM virtualization resource** + +**Description**: As there is no cloud O&M user interface at most of the edge cloud, the + virtualization resources of different edge should be displayed and updated somewhere + at the central cloud or large edge cloud or multi-cloud management platform + +**Preconditions**: + +1. A multi-cloud system has been setup and operate normally (at least two cloud, one + plays as the center of edge and the rest plays as the edge) + +2. the edge cloud has been managed by the center of edge (could be cantral cloud or + large edge cloud or multi-cloud management platform) + +**Steps**: + +1. Log into "center of edge" using admin account, and check the resource information + of managed edge VIM including host, VM, CPU, resource usage rate and etc. + +2. delete a VM in the edge cloud and recheck the resource information of this edge + cloud in the "center of edge" + +**Expected outcome**: + +1. The general resource information of edge cloud could be found in the "center of + edge" and it's correct + +2. the information can be updated in the "center of edge" within 5 minutes automatically + or be manually uppdated immediately + +---------------------------------------- + +**Test case #13: Support remote upgrading of edge VIM from "center of edge"** + +**Description**: As there might be no cloud O&M stuff at most of the dege cloud, the + edge system should support remote upgrading of edge VIM from "centrer of edge" + +**Preconditions**: + +1. A multi-cloud system are running normally + +2. At least one edge cloud has been managed by the "center of edge" or the "center + of edge" can access the edge cloud and manage its resources remotely + +3. At least one VM running on the edge cloud + +4. Patch is ready + +**Steps**: + +1. Record the software version of edge cloud + +2. Log into "center of edge" using admin account and go to the "software management" + or "Patch management" page (CLI is acceptable) + +3. Upload the patch and apply it to the edge cloud + +4. check the software version of edge cloud aftter upgrading + +5. Roll back the patch + +6. Check the software version after rolling back + +**Expected outcome**: + +1. Patch can be applied/removed to/from the edge cloud successfully and the version + number is correct after upgrading/rolling back + +2. VM running normally during upgrading/rolling back process + +---------------------------------------- + +**Test case #14: Alarm/warning from edge is displayed at the "center of edge"** + +**Description**: Mutli-cloud system should support centralized alarm/warning display + +**Preconditions**: + +1. A mutli-cloud system are running normally + +2. At least one edge cloud has been managed by the "center of edge" or from the "center + of edge" can access the edge cloud + +**Steps**: + +1. Create an alarm at edge cloud by killing an important openstack process such as + mysql, nova-api, nova-compute and etc. + +2. check corresponding alarm displayed on alarm related page at "center of edge" + +**Expected outcome**: Alarm from edge cloud can be displayed at "center of edge" + +---------------------------------------- + +**Test case #15: Management database & configuration data backup** + +**Description**: Multi-cloud system should support that the management database and + configuration data of edge can be backed up to "center of edge" or to local edge. + And those data can be recovered + +**Preconditions**: + +1. A multi-cloud system are running normally + +2. At least one edge cloud has been managed by the "center of edge" + +**Steps**: + +1. Log in to "center of edge" using admin acount, and go to "data backup" related page + +2. choose an edge cloud and choose a file or a server as the beckup destination (the + destination could be backend storage or an outside ftp server at "center of edge", + or it could be a local file directory) + +3. Fully backup the management database and configuration data of the chosen edge + cloud to the chosen storage destination + +4. Create a VM in the edge cloud + +5. Recover the backup data to the edge and check whether the VM exist + +(If using GUI, the original operation should start with log into "center of edge" not the edge cloud; CLI is also acceptable) + +**Expected outcome**: + +1. After step 3, the data can be backed up to s pointde place + +2. After step 5, the newly created VM does not exist diff --git a/docs/development/requirements/index.rst b/docs/development/requirements/index.rst index 4eb077b..d8d6b1e 100644 --- a/docs/development/requirements/index.rst +++ b/docs/development/requirements/index.rst @@ -12,4 +12,4 @@ Edge Cloud Requirement in OPNFV :maxdepth: 2 requirements.rst - + edge_cloud_test_case_reference.rst -- cgit 1.2.3-korg