Page History

...

Based on feedback, the proposal is to make a heatbridge microservice which can handle the AAI update (heatbridge).

The following diagram illustrates two cases.

Image Added

Case 1 - OpenStack Heatbridge

The current gerrits to add Heatbridge to SO ( https://gerrit.onap.org/r/78155 , https://gerrit.onap.org/r/78612 ) once merged, can then be refactored into a heatbridge microservice within SO fairly easily (Steve Smokowski)

1. Either during the SO VNF adapter vfModule create or from a new BPMN workflow step, invoke the heatbridge microservice.
2. The Heatbridge microservice will use Openstack queries (which could even go via Multicloud via the Multicloud Openstack proxy API) to query information about the vfModule in the cloud region.
3. The Heatbridge microservice updates AAI

Case 2 - Non-OpenStack clouds

For this case, to explore providing Heatbridge-like functionality for non-Openstack cloud regions (e.g. Kubernetes, etc.), the Heatbridge microservice invokes Multicloud with a single API call (vs. a series of queries in the Openstack case) to perform the AAI update and the appropriate Multicloud plugin will query the cloud region and handle the AAI update for the workload.

1. Either during the SO VNF adapter vfModule create or from a new BPMN workflow step, invoke the heatbridge microservice.
2. Invoke Heatbridge microservice with a call to perform the heatbridge function - see: https://gerrit.onap.org/r/82183 for what this call could look like.
3. The relevant Multicloud plugin queries the cloud region and then updates AAI.

In later releases, it seems likely that supporting other types of cloud regions will drive some enhancements to the AAI schema to make it less OpenStack biased.  Also, it's possible the heatbridge microservice, as illustrated above could migrate to the Multicloud project.  These topics will need further discussion beyond the Dublin timeframe.

Phase 1 - make it work for OpenStack

Whether using the SO OpenStack VNF adapter or the SO Multicloud VNF plugin adapter, the following diagram illustrates the vfModule creation step and the following heatbridge step.

Image Modified

1. Invoke SO VNF adapter to create vfModule
   1. SO OpenStack VNF adapter
   2. SO Multicloud VNF plugin adapter
2. SO VNF adapter creates vfModule
   1. SO directly interacts with the OpenStack cloud
   2. Multicloud adapter calls Multicloud which handles creating the vfModule
3. If vfModule was successful, new workflow step invokes new Heatbridge microservice
4. Query the OpenStack cloud for information
   1. If 1a, 2a path was followed, the microservice communicates directly to OpenStack to query info
   2. If Multicloud path is being used, query Openstack via the Multicloud Openstack API
5. Update AAI with info

Most of this code is already more or less written - except for creation of a new BPMN workflow step and packaging the heatbridge code as a microservice.

The API between SO and Multicloud is already in place, and the code to query OpenStack and update AAI is already developed. (this gerrit and related gerrit's https://gerrit.onap.org/r/#/c/78155/ )

In the Multicloud path, if a non-OpenStack cloud is invoked by the Heatbridge microservice, then some kind of error or stub reply is made.

Phase 2 - support non-OpenStack clouds

More work is required to support non-Openstack clouds since current heatbridge code is for OpenStack.  The following diagram (with the vfModule create step removed for simplicity) illustrates:

Image Modified

1. As in step 3 in phase 1 above, invoke the Heatbridge microservice
2. If the cloud region is not OpenStack, the difference is in how the microservice talks to Multicloud.  Instead of the OpenStack API, either a generic query API needs to be developed that is supported by the Multicloud plugins. (or, maybe the non-OpenStack plugins just respond with data in the same format as OpenStack would respond).
3. Either map data coming from the generic query API response from Multicloud to format needed to update AAI (or, no change if all Multicloud plugins respond with data looking like OpenStack responses).
   
   1. (arrow 3a) - alternative path suggested by Bin Yang.  In this case, the cloud specific plugin in Multicloud handles querying the cloud and updates AAI directly. Are there any drawbacks or limitations to this approach?  

Proposed Approach - via Multicloud VNF Plugin Adapter

...