...
- The following diagram depicts the component architecture.
- The VNFM Adapter will be a SO sub-component; packaged as a docker and running in a container.
- VNFM will register into A&AI ESR and VNFM Adapter will locate a proper VNFM based on VNF NF Type or others.
- Communications between the VNFM Adapter and SVNFM will be SOL003 API-based.
- Communications between the SO BPMN Infra VNFM Adapter REST Client and the VNFM Adapter NBI will be SO-specific; i.e., it does not follow ETSI standards at this time.
- SO SDC Controller receives SOL001/SOL004-based CSAR from SDC, and stores the CSAR reference URLs to TOSCA_CSAR database table.
- Currently, VNF package output from SDC is not ETSI alignment. For nowIf SDC does not support it Dublin, use the standard package under SDC the artifact directory (e.g., Artifact/Deployment/Others)
- In Dublin release, there could be two CSAR file contents: one for the original CSAR and one for ONAP-compliant CSAR (maybe the ONAP-compliant CSAR includes the original package)
- It is assumed that SDC keeps the original vendor VNF packages in their repository, and VNFM Adapter retrieves the original vendor CSAR files from the repository.
- New VNF-level workflows that use VNFM Adapter will be implemented, and these new workflows will be invoked from the (Network) Service-level workflows based on VNF type and other criteria.
- Unlike the existing SO VNF/VF-Module workflows, the new VNF-level/VF-Module-level workflows will NOT interact with OpenStack directly. The workflows will delegate the VNF LCM requests to VNFM Adapter, and VNFM Adapter will delegate the requests to VNFM further. Then, VNFM will interact with VIM directly. In Dublin release, the direct mode of resource management will be supported as depicted above.
...