This page summarizes the end to end interactions used between SO and Multicloud (and other components) to instantiate K8S and HPA Policy driven use cases.

Service distribution --> SO

Cloud artifact is included with a minimal Heat zip package:

Naming convention: <arbitrary>_cloudtech_k8s_charts.tgz


SO receives notification on Service distribution of the artifacts:


<arbitrary>_cloudtech_k8s_charts.env (apparently generated by SDC)

SO distribution notes an error for the above two items - but not blocking error

SO-2027 - Getting issue details... STATUS

Configuration of SO to use the VNF Plugin Adapter (instead of Openstack VNF Adapter)

Edit the configmap of the BPMN pod to use the v2 vnf api endpoint:

kubectl -n onap edit configmap dev-so-so-bpmn-infra-app-configmap

- vnf:

          endpoint: http://so-openstack-adapter.onap:8087/services/VnfAdapter


            endpoint: http://so-openstack-adapter.onap:8087/services/rest/v1/vnf

+ vnf:

          endpoint: http://so-openstack-adapter.onap:8087/services/VnfAdapter


            endpoint: http://so-openstack-adapter.onap:8087/services/rest/v2/vnfs 

Delete the pod and let it respawn with new config

Alternatively, modify the bpmn value overrides file before deploying SO.

SO-1448 - Getting issue details... STATUS   (fix this issue to allow coexistance of Openstack adapter and plugin adapter - could be as simple as using v2 API all the time?)

Configuration / Registration of Clouds in AAI and Multicloud

Register the kube config file with the CloudOwner and CloudRegion directly to the Multicloud K8S plugin - see [1]

    1. Register cloud with ESR, Add complex and register with Multicloud
    2. For K8S clouds, an extra step is required:
    3. For HPA cases using OOF homing, the BPMN flow handles ensuring that the CloudRegion is present in the catalogdb 'cloud_sites' table.
    4. For non-OOF homing cases, the CloudRegion must be inserted into 'cloud_sites'.  Key columns used by the SO Multicloud VNF Plugin adapter are the 'cloud_region' (sic?) and the 'orchestrator' column - which must be set to 'multicloud'.  This is used by the VNF Plugin Adapter to select the Multicloud plugin for instantiation of the vfModule.  The multicloud adapter does not require the identity record in catalogdb, so the DEFAULT identity record is fine for using in the cloud_sites record.

SO-2028 - Getting issue details... STATUS

SDNC Preload

Performed as usual. 

Service Instantiation - e.g. VID or REST - using VNF-API

SO Service Instance create API

For HPA use case, specify OOF Homing in UserParams

BPMN calls OOF to obtain homing solution - which is sent to the VNF adapter as CloudOwner and CloudRegion parameters.  The OOF directives are placed into the 'oof_directives' parameter which is passed to Multicloud and is used to override the flavor of the vnfc for the destination cloud region based on the OOF solution.

SO VNF create API

SO vfModule create API

SO Multicloud plugin adapter invokes the Multicloud infra_workload API to instantiate the vfModule

GET with query paramter by workload name (e.g. stack name)

POST to create workload

GET with query by workload-id used to poll for create complete

POST with workload-id to trigger Multicloud to perform AAI update (e.g. heatbridge)

GET with query by workload-id to poll for update complete

JIRA: separate step for AAI update

JIRA: clean up infra_workload API

For K8S use case, profile instance information is passed in via the userParams,  With VID, these can be supplied with the Supplementary JSON file on the VID screen

TODO:  verify that SDNC is not required for K8S 'dummy' heat templates.  It may be necessary to add a bit more into the 'dummy' heat template to satisfy the SDNC query.  (currently SDNC preload was performed in this case to avoid an error that appeared to be coming from SDNC)

For SO Multicloud plugin adapter, the 'template_type' needs to be supplied.  Currently this has been done by adding it as a UserParam also.  template_type == 'heat' is the currently supported template type.

After create is complete: SO updates AAI with vfModule information (perhaps this should be done by Multicloud? JIRA

Other testing verification items:

  • Testing with GR-API
  • Use of CDS

Summary of next work items:

E Release Timeframe - Distribution error for type SO for CLOUD_TECHNOLOGY_SPECIFIC_ARTIFACTS - Support v1 and v2 vnf adapter API (investigate if v2 API can be used to replace use of v1) - support for secure communications between SO and Multicloud - Determine heat template needed to avoid preload for k8s workload - Provide a better method for entering SO cloud_site entry (investigate if do-able in E or if more changes required, then in F)K8S tenant support

MULTICLOUD-680 - Getting issue details... STATUS   K8S Multicloud plugin should register a (at least a default) tenant in AAI update cloud registration (current workaround has been to use the mutlicloud windriver plugin to register an openstack tenant)

F Release Timeframe (investigation, design, planning should start during E timeframe) - SO Multicloud plugin to Multicloud improvements

  • vFW closed loop functionality verification - for SO multicloud plugin, vFW K8S
  • VL support enhancements - AAI update for VNF improvements (e.g. Heatbridge)

Multitenancy in K8S  ? - refer to: ONAP Cloud Native Multi tenancy proposal

Reference links for more details:




Readthedocs links:

  • No labels

1 Comment

  1. Bin Yang Seshu Kumar Mudiganti Marcus Williams Itohan Ukponmwan Kiran Kamineni Akhila Kishore   Following discussions at the DDF, I've made this page and summarized the interactions and configurations performed by SO for the End to End K8s and HPA use cases.  I've linked in known jiras.

    I'll check back in on 6/23 (on vacation this week with limited online access) - if any clarifications or information is required, add to the page or put in the comments.