This Wiki page is intended to capture and define the integration tests which exercise the Auto Use Cases from a testability perspective.
This project focuses on somewhere in between L3 and L2 in the following figure.
Reference to Auto-UC-01
The tests below are hypothetical examples intended to illustrate an organizational approach to developing tests that demonstrate the value of ONAP closed-loop support for improving platform resiliency. The goal for these tests is to focus first on the most commonly occurring stresses, and to expand toward chaos monkey type testing over time.
Physical Infra Failure
|Migration upon host failure||Compute host power is interrupted by IPMI command, and affected workloads are migrated to other available hosts.|
|auto-resiliency-pif-002||Migration upon disk failure||Disk volumes are unmounted, and affected workloads are migrated to other available hosts.|
|auto-resiliency-pif-003||Migration upon link failure||Traffic on links is interrupted/corrupted by switch admin commands, and affected workloads are migrated to other available hosts.|
|auto-resiliency-pif-004||Migration upon NIC failure||NIC ports are disabled by host commands, and affected workloads are migrated to other available hosts.|
|Virtual Infra Failure||auto-resiliency-vif-001||OpenStack compute host service fail||Core OpenStack service processes on compute hosts are terminated, and auto-restored, or affected workloads are migrated to other available hosts.|
|auto-resiliency-vif-002||SDNC service fail||Core SDNC service processes are terminated, and auto-restored.|
|auto-resiliency-vif-003||OVS fail||OVS bridges are disabled, and affected workloads are migrated to other available hosts.|
|Security||auto-resiliency-sec-001||Host tampering||Host tampering is detected, the host is fenced, and affected workloads are migrated to other available hosts.|
|auto-resiliency-sec-002||Host intrusion||Host intrusion attempts are detected, an offending workload, device, or flow is identified and fenced, and as needed affected workloads are migrated to other available hosts.|
|auto-resiliency-sec-003||Network intrusion||Network intrusion attempts are detected, and an offending flow is identified and fenced.|
|Spin up an instance of specific type VNF||Spin up a vCPE/vFW/vDHCP/vAAA instance,when manually operates on Portal.|
|auto-vcpe-onboarding-002||Spin up VNF instances with a workflow||Spin up vCPE/vFW/vDHCP/vAAA instances in sequence, when related MSO workflow is developed and executed|
|Scaling Up/Down||auto-vcpe-scaling-001||Scaling up||Scaling up when the CPU usages of all the existing VNF instances are beyond the limit assigned by Policy.|
|auto-vcpe-scaling-002||Scaling down||Scaling down when a VNF instance have been idle for a period of time, which is assigned by Policy.|
|Zero Touch Provisioning||auto-vcpe-ztp-001||Authorizing and Addressing||Authorizing and Addressing with vAAA and vDHCP, when ThinCPE first powers up and new host joins.|
|auto-vcpe-ztp-002||VPN establishing||VPN establishing, optionally with VxLAN/IPSec/MPLS, after ThinCPE is authorized and addressed|
|auto-vcpe-ztp-003||Access controlling||Access controlling with vFW, when new security policy is proposed on Portal.|