...

Following enhancements are being done in R3:

1. Support for vFW and vDNS use cases
   1. In R2, only vCPE workflow in enhanced to call OOF for homing decisions. Changes are being done in R3 to ensure that SO workflow for vFW and vDNS call OOF for homing decisions. Hence test plan should ensure that both vFW and vDNS use cases are tested with HPA feature.
2. Usage of Multi-Cloud service instead of SO directly communicating with openstack instance in the cloud regions
   1. In R2, E2E testing was done with SO bypassing Multi-Cloud service.  In R3, SO calls the Multi-Cloud Service. Multi-Cloud service, in turn, communicates with Openstack HEAT in the cloud-regions. Test plan should ensure that SO is configured to work with Multi-Cloud
3. Derivation of HEAT parameters from OOF homing decisions
   1. In R2, HEAT parameters and its values are generated based on OOF homing decision as SO was calling Openstack HEAT service directly. In R3, as mentioned above, the communication with HEAT is moved to Multi-Cloud service. As part of that changes are made to Multi-Cloud API to accept oof_directives and sdnc_directives.  Multi-Cloud service is expected to generate HEAT parameters & it values from these directives.  Test plan should ensure that HEAT parameters and values generated by Multi-Cloud are as expected.
4. SRIOV-NIC HPA feature support in R3:
   1. SRIOV-NIC HPA feature is added in R3.  It allows VFCs that require SRIOV-NIC VFs would be placed in the right site and with right flavor. Test plan should ensure that OOF makes right decisions and right Openstack flavor is selected.
5. Cloud-region and flavor selection enhancements in OOF
   1. In R2, OOF is selecting always the first region that match all mandatory requirements of VNF. If there are multiple regions that satisfy mandatory requirements of VNF, then selection is expected to be based on the best score.  This enhancement is being done in R3.  Test plan should cover to ensure that the right region with best score is selected in case of multiple regions.
6. Cloud-specific features as a HPA feature:
   1. VMWare is adding some cloud-specific features as HPA feature and thereby making the cloud technology specific feature agnostic to ONAP. Test plan should ensure that VIO specific features are tested without having to have any special logic in ONAP (except for VIO plugin) along with rest of HPA features.
7. Support for VoLTE use case
   1. In R2, SO is only component calling OOF for homing decisions and hence HPA feature only works with SO based use cases.  In R3, VF-C (NSLCM) is being enhanced to talk to OOF and hence VF-C based use cases and corresponding VNFs can leverage the OOF returned information such as the cloud-region and flavor to use.  Test plan should ensure that VOLTE use case is tested to ensure that right openstack flavor is selected.  These test cases test multiple functions such as 'auto creation of HPA policies from TOSCA', 'SDC client in policy framework' and few changes made in SDC to fix some gaps in TOSCA parser.
8. HPA telemetry and HPA state based placement decisions (stretch goal, may not happen in R3 time frame) :  No test plan is going to be written for this.

Test plans

Intention is to keep number of test cases to minimum.  We believe that three test items are needed.

Test 1: Covering enhancements 1 to 5 in above list.

Test 2:  Covers enhancement 6.

Test 3:  Covers enhancement 7

Test Plan 1

Scenario:

• ONAP managing 3 cloud-regions.
  • Cloud-region1, Cloud-region2 and Cloud-region3
  • All cloud regions are controlled by Openstack (with HEAT service)
• Each cloud-region has three flavors
  • Cloud-region1:
    • Flavor 11:
      • 2 vcpus, 2 Gbytes of memory, 20Gb disk
      • Numa page size: 2Mbytes and number pages 4
    • Flavor 12:
      • 2 vcpus, 2 Gbytes of memory, 20Gb disk
      • Numa page size: 2Mbytes and number pages 6
      • SRIOV-NIC with PCI Vendor: 1234 and PCI device :3456 on physical network 1 (physnet1) with support for 2VFs
    • Flavor 13:
      • 2 vcpus, 2 Gbytes of memory, 20Gb disk
      • Numa page size: 2Mbytes and number pages 6
      • SRIOV-NIC with PCI Vendor: 1234 and PCI device :3456 on physical network 1 (physnet1) with support for 1VFs
      • SRIOV-NIC with PCI Vendor: 1234 and PCI device :3456 on physical network 1 (physnet2) with support for 1VFs
  • Cloud-region2:
    • Flavor 21:
      • 2 vcpus, 4 Gbytes of memory, 20Gb disk
      • Numa page size: 2Mbytes and number pages 4
      • SRIOV (non-NIC) with PCI vendor: 1234 Device ID: 7890 Count as 2.
    • Flavor 22:
      • 2 vcpus, 6 Gbytes of memory, 20Gb disk
      • Numa page size: 2Mbytes and number pages 6
      • SRIOV-NIC with PCI Vendor: 1234 and PCI device :3456 on physical network 1 (physnet1) with support for 2VFs
    • Flavor 23:
      • 2 vcpus, 2 Gbytes of memory, 20Gb disk
      • Numa page size: 2Mbytes and number pages 6
      • SRIOV-NIC with PCI Vendor: 1234 and PCI device :3456 on physical network 1 (physnet1) with support for 1VFs
      • SRIOV-NIC with PCI Vendor: 1234 and PCI device :3456 on physical network 1 (physnet2) with support for 1VFs
  • Cloud-region3:
    • Flavor 31:
    • • 2 vcpus, 4 Gbytes of memory, 20Gb disk
      • Numa page size: 2Mbytes and number pages 4
      • SRIOV (non-NIC) with PCI vendor: 1234 Device ID: 7890 Count as 2.
      Flavor 32:
      • 2 vcpus, 8 Gbytes of memory, 20Gb disk
      • Numa page size: 4Mbytes and number pages 6
      Flavor 33:
      • 2 vcpus, 2 Gbytes of memory, 20Gb disk
      • Numa page size: 2Mbytes and number pages 6
• Test 1 (Basic)
  • Scenario:
    • Use vFW VNF (firewall, generator and sink)
    • firewall part of  policy asking for:
      • Mandatory:
      • 2 vcpus
      • >4Gbytes of memory
      • <10Gbytes of disk
      • Numa page size : 4Mbytes and pages 5
      • Optional:
      • SRIOV PCI vendor 1234 and device ID 7890 with PCI count 1 with score 100
    • Generator part of policy asking for:
      • Mandatory;
      • 1 vcpu
      • 6Gbytes of memory
      • <10Gbytes of disk
      • No Numa
      • No optional
    • Sink part of policy asking for:
      • No mandatory
      • No optional
    • Modify vFW HOT templates with right label and ensure that those labels are referred in the policy properly.
  • Instantiate the VNF
  • Check for results:
    • It would have selected Cloud-region3 with flavor31 for firewallVM, flavor32 for for generator and any flavor for sink.
    • Why region 3:  Since only Flavor32 has 8Gbytes of memory that can match Generator policy requirements.
• Test 2: