You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Background:

Multiple enhancements are happening in R3 with respect to HPA.  This test plan is to ensure that changes and new enhancements being added to R3 are tested (Preferably testing by developers as well as part of integration testing).

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 exposed through HPA Policy framework:
    1. VMWare is adding some cloud-specific features using HPA policy 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 vCPE 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 vCPE 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.


HPA & Cloud Agnostic Policy & A&AI data examples: OOF R3 HPA & Cloud Agnostic policies


Test plans

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

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

Test Plan 2:  Covers enhancement 6.

Test Plan 3:  Covers enhancement 7

Test Plan 1

This test plan covers the tests related to testing

  • Support for vFW use case
  • Multi-Cloud API changes with oof_directives and sdnc_directives.
  • Multi-Cloud preparing HEAT parameters from oof_directives and sdnc_directives
  • SRIOV-NIC feature
  • Region selection based on score

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 :7654 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: 8Mbytes and number pages 6
        Flavor 33:
        • 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 (physnet3) with support for 1VFs
        • SRIOV-NIC with PCI Vendor: 1234 and PCI device :3456 on physical network 1 (physnet4) with support for 1VFs
  • 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 : 2Mbytes and pages 4
        • 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
          • 7Gbytes 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:  (to test SRIOV-NIC feature) (to ensure that right cloud-region is selected based on score)
    • Scenario:
      • Use vFW VNF (firewall, generator and sink)
      • Say generator and one side of firewall are connected over physnet1
      • And other side of firewall and sink are connected on physical network2 (physnet2)
      • firewall part of  policy asking for:
        • Mandatory:
          • SRIOV-NIC vendor 1234, 3456 device ID on physnet1, count 1
          • SRIOV-NIC vendor 1234, 3456 device ID on physnet2, count 1
      • Generator part of policy asking for:
        • Mandatory;
          • SRIOV-NIC vendor 1234, 3456 device ID on physnet1, count 2
      • Sink part of policy asking for:
        • mandatory
          • SRIOV-NIC vendor 1234, 3456 device ID on physnet2, count 1
        • 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-region1 with flavor13 for firewallVM, flavor12 for for generator and flavor13 for sink.

  • Test 3 (to ensure that right cloud-region is selected based on score)
    • Scenario:
      • Use vFW VNF (firewall, generator and sink)
      • firewall part of  policy asking for:
        • Mandatory:
        • 2 vcpus
        • 2Gbytes of memory
        • <10Gbytes of disk
        • Numa page size : 4Mbytes and pages 4
        • 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
          • <10Gbytes of disk
          • 2Gbytes of memory
        • optional
          • >=4Gbytes of Numa page size with Numa count 2 -  score 200
      • 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 8Mbyte of NUMA pages and the total score is 300 and in case of region 2, the score is only 100.

Test Plan 2 

This test plan covers the tests related to testing

  • Support for vFW use case
  • Multi-Cloud API changes with oof_directives and sdnc_directives.
  • Multi-Cloud preparing HEAT parameters from oof_directives and sdnc_directives 

Scenario:

  • ONAP managing 1 cloud-region 3.
    • Cloud-region 3
    • All cloud regions are controlled by VMware Integrated Openstack (with HEAT service)
  • Each cloud-region has three flavors
    • Cloud-region 1:
      • Flavor 31:
      • Flavor 32:
        • 2 vcpus, 8 Gbytes of memory, 20Gb disk 
        • Infrastructure Resource Isolation for VNF w/ Burstable QoS, Oversubscription Percentage (Definition: Cloud Agnostic Intent and Mappings) 
        Flavor 33:
        • 2 vcpus, 2 Gbytes of memory, 20Gb disk 
  • Test 1 (Basic)
    • Scenario:
      • Use vFW VNF (firewall, generator and sink)
      • firewall part of  policy asking for:
      • Generator part of policy asking for:
        • Mandatory;
          • 1 vcpu
          • 7Gbytes of memory
          • <10Gbytes of disk
          • Infrastructure Resource Isolation for VNF w/ Burstable QoS, Oversubscription Percentage (Definition: Cloud Agnostic Intent and Mappings) 
      • 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.

Test Plan 3 : VF-C HPA testing (Huang Haibin to fill up)


  • No labels