Date: Fri, 29 Mar 2024 14:55:14 +0000 (UTC)
Message-ID: <402478335.130764.1711724114314@aws-us-west-2-onap-confluence-1.web.codeaurora.org>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_130763_843308919.1711724114313"
------=_Part_130763_843308919.1711724114313
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Background:
Multiple enhancements are happening in R3 with respect to HPA. Thi=
s test plan is to ensure that changes and new enhancements being added to R=
3 are tested (Preferably testing by developers as well as part of integrati=
on testing).
Following enhancements are being done in R3:
- Support for vFW and vDNS use cases
- 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 c=
all OOF for homing decisions. Hence test plan should ensure that both vFW a=
nd vDNS use cases are tested with HPA feature.
- Usage of Multi-Cloud service instead of SO directly communicating with =
openstack instance in the cloud regions
- 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, co=
mmunicates with Openstack HEAT in the cloud-regions. Test plan should ensur=
e that SO is configured to work with Multi-Cloud
- Derivation of HEAT parameters from OOF homing decisions
- 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 ment=
ioned above, the communication with HEAT is moved to Multi-Cloud service. A=
s part of that changes are made to Multi-Cloud API to accept oof_directives=
and sdnc_directives. Multi-Cloud service is expected to generate HEA=
T parameters & it values from these directives. Test plan should =
ensure that HEAT parameters and values generated by Multi-Cloud are as expe=
cted.
- SRIOV-NIC HPA feature support in R3
- 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. Tes=
t plan should ensure that OOF makes right decisions and right Openstack fla=
vor is selected.
- Cloud-region and flavor selection enhancements in OOF
- In R2, OOF is selecting always the first region that match all mandator=
y requirements of VNF. If there are multiple regions that satisfy mandatory=
requirements of VNF, then selection is expected to be based on the best sc=
ore. This enhancement is being done in R3. Test plan should cov=
er to ensure that the right region with best score is selected in case of m=
ultiple regions.
- Cloud-specific features exposed through HPA Policy framework:
- VMWare is adding some cloud-specific features using HPA policy and ther=
eby making the cloud technology specific feature agnostic to ONAP. Test pla=
n should ensure that VIO specific features are tested without having to hav=
e any special logic in ONAP (except for VIO plugin) along with rest of HPA =
features.
- Support for vCPE use case
- 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) i=
s being enhanced to talk to OOF and hence VF-C based use cases and correspo=
nding VNFs can leverage the OOF returned information such as the cloud-regi=
on and flavor to use. Test plan should ensure that vCPE use case is t=
ested to ensure that right openstack flavor is selected. These test c=
ases test multiple functions such as 'auto creation of HPA policies from TO=
SCA', 'SDC client in policy framework' and few changes made in SDC to fix s=
ome gaps in TOSCA parser.
- HPA telemetry and HPA state based placement decisions (stretch goal, ma=
y 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 t=
hat 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/vDNS use case
- Multi-Cloud API changes with oof_directives and sdnc_directives.
- Multi-Cloud preparing HEAT parameters from oof_directives and sdnc_dire=
ctives
- 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, 512 Mbytes of memory, 20Gb disk
- Numa page size: 2Mbytes
- Flavor 12:
- 2 vcpus, 2048 Mbytes of memory, 20Gb disk
- Numa page size: 2Mbytes
- SRIOV-NIC with PCI Vendor: 8086 and PCI device :154C on physical networ=
k 1(private-1) with support for 2VFs
- Flavor 13:
- 2 vcpus, 2048 Mbytes of memory, 20Gb disk
- Numa page size: 2Mbytes
- SRIOV-NIC with PCI Vendor: 8086 and PCI device :154C on physical networ=
k 2(private-1) with support for 1VFs
- Cloud-region2 :
- Flavor 21:
- 2 vcpus, 512 Mbytes of memory, 20Gb disk
- Numa page size: 2Mbytes and number pages 4
- Cpu thread policy=3Disolate and cpu pinning policy is dedicated=
span>
- Flavor 22:
- 2 vcpus, 2048 Mbytes of memory, 20Gb disk
- Numa page size: 2Mbytes
- SRIOV-NIC with PCI Vendor: 8086 and PCI device :154C on physical networ=
k 2 (private-1) with support for 2VFs
- Flavor 23:
- 2 vcpus, 2048 Mbytes of memory, 20Gb disk
- Numa page size: 2Mbytes
- SRIOV-NIC with PCI Vendor: 8086 and PCI device :154C on physical networ=
k 2(shared-1) with support for 2VFs
- Cloud-region3:
- Flavor 31:
- 2 vcpus, 512 Mbytes of memory, 20Gb disk
- Numa page size: 2Mbytes
- Cpu thread policy=3Disolate and cpu pinning policy is dedicated=
span>
- Flavor 32:
- 2 vcpus, 8 Gbytes of memory, 20Gb disk
- Numa page size: 1Gbytes
- Flavor 33:
- 2 vcpus, 4 Gbytes of memory, 20Gb disk
- Numa page size: 2Mbytes
- SRIOV-NIC with PCI Vendor: 8086 and PCI device :154C on physical networ=
k 2(shared-1) with support for 1VF
&=
nbsp; vFW TEST CASES
- Test 1 (Basic)
- Scenario:
- Use vFW VNF (firewall, generator and sink)
- firewall part of policy asking for:
- Mandatory:
- 2 vcpus
- 512Mbytes of memory
- >=3D10Gbytes of disk
- Numa page size : 2Mbytes
- Optional:
- dedicated cpu pinning and policy and isolated cpu thread policy with sc=
ore of 100
- Generator part of policy asking for:
- Mandatory;
- 1 vcpu
- 7Gbytes of memory
- >=3D10Gbytes of disk
- No Numa
- No optional
- Sink part of policy asking for:
- 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, flav=
or32 for for generator and any flavor for sink.
- Why region 3: Since only Flavor32 has 8Gbytes of memory that can =
match Generator policy requirements and only flavor31 has cpu thread policy=
of isolated and cpu pinning policy of dedicated
- Test 2: (to test SRIOV-NIC feature) (to ensure that right cloud-r=
egion is selected based on score)
- Scenario:
- Use vFW VNF (firewall, generator and sink)
- Say vFW and sink are connected together on private-1
- firewall part of policy asking for:
- Mandatory:
- SRIOV-NIC vendor 8086, 154C device ID on private-1, count 2
- Generator part of policy asking for:
- Mandatory;
- SRIOV-NIC vendor 8086, 154C device ID on private-1, count 1
- Sink part of policy asking for:
- Mandatory
- SRIOV-NIC vendor 8086, 154C device ID on private-1, 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 flavor12 for firewallVM and f=
lavor13 for generator and sink VMs.
- Why region 1: only cloud region one has flavors that support the unique=
combinations perfectly
=E2=80=A2 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
- 4Gbytes of memory
- 10Gbytes of disk
- Numa page size : 2Mbytes and pages 6
- Optional:
- SRIOV-NIC vendor 8086, 154C device ID on shared-1, count 1 - score 100<=
/li>
- Generator part of policy asking for:
- Mandatory;
- 1 vcpu
- >=3D10Gbytes of disk
- 2Gbytes of memory
- optional
- >=3D1Gbytes of Numa page size with Numa count 2 - score 200
- Sink part of policy asking for:
- 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 flavor33 for firewallVM, flav=
or32 for generator and any flavor for sink.
- Why region 3: Since only Flavor32 has 1Gbyte of NUMA pages and th=
e total score is 300
=
vDNS TEST CASES
- Test 1 (Basic)
- Scenario:
- Use vLB VNF (loadbalancer, generator and vDNS)
- vLB part of policy asking for:
- Mandatory:
- 2 vcpus
- 512Mbytes of memory
- 10Gbytes of disk
- Numa page size : 2Mbytes
- Optional:
- dedicated cpu pinning and policy and isolated cpu thread policy with sc=
ore of 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:
- Modify vLB 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 vLB VM, flavor32=
for for generator and any flavor for vDNS.
- 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-r=
egion is selected based on score)
- Scenario:
- Use vLB VNF (vlb, vpg and vdns)
- vlb part of policy asking for:
- Mandatory:
- SRIOV-NIC vendor 8086, 154C device ID on private-1, count 2
- vpg part of policy asking for:
- Mandatory;
- SRIOV-NIC vendor 8086, 154C device ID on private-1, count 1
- vdns part of policy asking for:
- Mandatory
- SRIOV-NIC vendor 8086, 154C device ID on private-1, count 1
- No optional
- Modify vLB 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 flavor12 for vlb and flavor13=
for vpg and vdns.
- Why region 1: This best meets its vf requirements
=E2=80=A2 Test 3 (to ensure that right cloud-region is selected based on=
score)
- Scenario:
- Use vLB VNF (vlb, vpg and vdns)
- vLB part of policy asking for:
- Mandatory:
- 2 vcpus
- 4Gbytes of memory
- 10Gbytes of disk
- Numa page size : 2Mbytes
- Optional:
- SRIOV-NIC vendor 8086, 154C device ID on shared-1, count 1 - score 100<=
/li>
- Generator part of policy asking for:
- Mandatory;
- 1 vcpu
- 10Gbytes of disk
- 2Gbytes of memory
- optional
- >=3D1Gbytes of Numa page size with Numa count 2 - score 200
- vdns part of policy asking for:
- Modify vLB 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 flavor33 for vLB, flavor32 fo=
r generator and any flavor for vdns.
- Why region 3: Since only Flavor32 has 1Gbyte of NUMA pages and th=
e total score is 300
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_dire=
ctives
- Cloud-agnostic Intent Feature
Scenario:
- ONAP managing 1 cloud-region.
- Cloud-region1
- All cloud regions are controlled by VMware Integrated Openstack (with H=
EAT service)
- Each cloud-region has three flavors
- Cloud-region 1:
-
- 2 vcpus, 4 Gbytes of memory, 20Gb disk
- Add following metadata:
- quota:memory_reservation_percent: 100
- quota:cpu_reservation_percent: 100
- Infrastructure Resource Isolation for VNF w/ Guaranteed QoS (Definition=
: Cloud Agn=
ostic Intent and Mappings)
onap.flavor2:
- name: onap.flavor2
- 2 vcpus, 8 Gbytes of memory, 20Gb disk
- Add following metadata:
- quota:memory_reservation_percent: 25
- quota:cpu_reservation_percent: 25
- Infrastructure Resource Isolation for VNF w/ Burstable QoS, Oversu=
bscription Percentage (Definition: Cloud Agnostic Intent and Mappings)
flavor3:
- name: flavor3
- 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, Oversu=
bscription Percentage > 20% (Definition: Cloud Agnostic Intent and Mappings)&nb=
sp;
- Sink part of policy asking for:
- 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 onap.flavor1 for firewallVM, =
onap.flavor2 for for generator and any flavor for sink.
Testing Steps:
- Create new project "ONAP" on VIO
- Create new user "onap_user" and grant it "admin" role, associate it to =
"ONAP" project.
- Follow above requirements to create 3 flavors on VIO
- Register VIO VIM info through ESR, "vim_type" choose "vmware", input th=
e user/password/project created in previous steps
- The VIM registration process will discover the "Infrastructure Resource=
Isolation for VNF" feature into A&AI, please check A&AI and see if=
related flavors were discovered or not.
- Add related policies for OOF to choose the correct flavor
- Trigger the vFW deployment process and see if the correct flavor are ch=
osen for VNFs.
Test Plan 3 : VF-C HPA testing
This test plan covers the tests related to testing
- Support for vCPE use case in VF-C
Scenario:
- ONAP managing 2 cloud-region which have three flavors.
- Cloud-region1:
- Flavor 11:
- 2 vcpus, 4 Gbytes of memory, 40Gb disk
- Numa page size: 2Mbytes and number pages 2048
- Flavor 12:
- 2 vcpus, 2 Gbytes of memory, 40Gb disk
- Huge page size: 2Mbytes and number pages 1024
- Flavor 13:
- 2 vcpus, 1 Gbytes of memory, 20Gb disk
- Numa page size: 2Mbytes and number pages 512
- Cloud-region2:
- Flavor 21:
- 2 vcpus, 1 Gbytes of memory, 20Gb disk
- Numa page size: 2Mbytes and number pages 512
- Flavor 22:
- 2 vcpus, 2 Gbytes of memory, 20Gb disk
- Numa page size: 2Mbytes and number pages 1024
- Flavor 23:
- 2 vcpus, 4 Gbytes of memory, 20Gb disk
- Huge page size: 2Mbytes and number pages 2048
- Test 1 (Basic)
- Scenario:
- Use vCPE (vinfra, vgw, vbng, vbrgemu and vgmux)
- vinfra =
part of policy asking for:
- Mandatory:
- 2 vcpus
- >=3D 2Gbytes of memory
- > 40Gbytes of disk
- Numa page size : 2Mbytes and pages 1024
- No optional:
- vgw part of policy asking for:
- Mandatory;
- 2 vcpu
- >=3D4Gbytes of memory
- >=3D 40Gbytes of disk
- No Numa
- No optional
- vbng part of policy asking for:
- Mandatory:
- 2 vcpus
- >=3D 2Gbytes of memory
- > 40Gbytes of disk
- Numa page size : 2Mbytes and pages 1024
- No optional
- vbrgemu part of policy asking for:
- Mandatory:
- 2 vcpus
- >=3D 2Gbytes of memory
- >=3D 40Gbytes of disk
- Numa page size : 2Mbytes and pages 1024
- No optional
- vgmux part of policy asking for:
- Mandatory:
- 2 vcpus
- >=3D 2Gbytes of memory
- > 40Gbytes of disk
- Numa page size : 2Mbytes and pages 1024
- No optional
- Instantiate the VNF
- Check for results:
- It would have selected Cloud-region1 with flavor11 for vgw and flavor12=
for all other vCPE VMs.
- Why region 1: Since only region 1 has support for both 40Gbytes d=
isk space and 4Gbytes memory
------=_Part_130763_843308919.1711724114313--