Support for vFW and vDNS use cases

In R2, only the vCPE SO workflow was enhanced to call OOF for homing decisions. In R3, SO workflows for vFW and vDNS will also call OOF for homing decisions.

SO

Default

Most of code will be in by Wednesday.

Test plan to ensure that both vFW and vDNS use cases are tested with HPA feature

Use of Multi-Cloud Service instead of SO for direct communication with OpenStack instances in cloud regions

In R2, as part of the vCPE workflow, SO bypassed the Multi-Cloud service and called OpenStack directly..  In R3, this will no longer be the case and SO will call the Multi-Cloud Service. Multi-Cloud service will, in turn, communicate with OpenStack instances within different cloud regions.

SO
Multi-Cloud

Default

Code being integrated late on Wednesday.

Test plan should ensure that SO is configured to work with Multi-Cloud Service.

Derivation of HEAT parameters from OOF homing decisions in the Multi-Cloud Service

In R2, vCPE HEAT template parameters and their values were generated by SO, based on OOF homing decisions because SO was calling Openstack directly. In R3, communication with OpenStack is moved to the Multi-Cloud Service and SO will no longer generate HEAT template parameters. Instead, the Multi-Cloud API will accept directives from OOF and SDN-C, passed as API call parameters.   Multi-Cloud service will generate HEAT template parameters based on these directives. 

SO
OOF
Multi-Cloud 

Default

Dependency on #2.

Test plan should ensure that HEAT parameters and values generated by Multi-Cloud are as expected.

SRIOV-NIC HPA feature support

SRIOV-NIC HPA feature is added in R3.

Multi-Cloud
SO 

Default

Dependency on #2 and #3.

Test plan should ensure that OOF makes right decisions and right Openstack flavor is selected.

Cloud-region and flavor selection enhancements in OOF

In R2, OOF always selected the first cloud region to satisfy all mandatory HPA requirements, even if multiple cloud regions were able to satisfy the requirements. In R3, OOF will use scoring to pick the right cloud region, such that the region with the highest score is always chosen.

OOF

Default

Test plan should cover to ensure that the right region with best score is selected in case of multiple regions.

Missing E2E integration testing, can be done after M4

Support for vCPE use case

In R2, vCPE orchestration was only possible using SO and HEAT templates. In R3, vCPE orchestration will also be possible using VF-C and partially ETSI NFV SOL001 v0.6.0 compliant TOSCA templates. As part of this change, VF-C (NSLCM) will be enhanced to communicate with OOF and use OOF supplied recommendations for placement.

VF-C
SDC
Policy

Test plan should ensure that vCPE use case is tested using both VF-C and SO. In either case, the same OpenStack flavor and cloud region should be selected for VNF placement.

HPA telemetry and HPA state based placement decisions

Stretch goal, may not happen in R3 time frame

Default

Modeling of VNF hardware platform requirements and dependencies as part of the VNFD information model and TOSCA data models.

Committed

Specification and validation of VNF hardware platform requirements and dependencies as part of the VNF package (TOSCA).

Committed

Use of VNFD supplied hardware platform requirements at on-boarding time to verify that infrastructure is capable of supporting VNF instantiation and operation.

stretchR3

Translation of VNFD supplied VNF hardware platform requirements into HPA related OOF homing and placement policies.

committed

Manual specification of HPA related OOF homing and placement policies based on hardware platform requirements.

Done

Use of VNF hardware platform requirements as constraint policies for optimized homing and resource placement of VNF components during VNF instantiation.

Done

Use of hardware platform telemetry in determination of the VNF instance health.

scheduled

Use of hardware platform telemetry to enhance OOF homing and placement decisions.

Multi-Cloud, AAI, OOF

committed

Use of VNF hardware platform dependencies as constraints for operation and remediation of running VNF instances.

delayedr4

Use of VNF hardware platform dependencies as constraints for VNF autoscaling.

delayedr4

Use of VNF hardware platform dependencies as constraints for VNF change management.

delayedr4

Discovery of hardware platform capabilities exposed by different VIMs.

Done

Modeling and persistence of discovered platform capabilities in the AA&I database.

Done

SRIOV Discovery.

commited

SRIOV Day 0 Configuration.

committed

VF-C/HPA integration.

committed

Format and content of the VNFD, as supplied via the CSAR file are unaffected by VNF on-boarding.

To be done

HPA requirements are unaffected by VNF on-boarding.

To be done

On-boarding of VNFs with HPA requirements fails if appropriate ONAP components  (e.g. HPA requirement interpreter plugin) are not found.

To be done

HPA requirement validation errors result in termination of the VNF on-boarding process.

To be done

VNFs with TOSCA-encoded VNFDs can be used to build network services.

To be done

VNFD and all of its content, HPA requirements included, remain immutable.

To be done

Policy and SO components are able to register as SDC distribution clients.

To be done

VNFD can be distributed through the SDC distribution framework.

To be done

HPA requirement parsing errors result in termination of the VNF distribution process.

To be done

VNFs with TOSCA-encoded VNFDs can be instantiated using VF-C.

To be done

VNFs with TOSCA-encoded VNFDs can be instantiated using SO.

To be done

The same VNF package can be used with all ONAP orchestrators.

To be done

HPA requirements are consistently interpreted by all orchestrators.

To be done

VNFs including SR-IOV NIC requirements with TOSCA-encoded VNFDs can be instantiated using VF-C.

To be done

502

VNFs including SR-IOV NIC requirements with TOSCA-encoded VNFDs can be instantiated using SO.

To be done

To be done