Heatbridge is currently a manual step that is executed after a VNF and its vfModules have been instantiated. What happens is that AAI is updated with details about the workload running in the cloud (e.g. vserver details, interface details, images, flavors).
There is interest in providing for this update to AAI to happen automatically instead of manually.
It is also of interest to provide this functionality generically for other cloud types. Let's call it something like 'AAI Workload Update' instead of 'heatbridge'.
Proposed Approach - make a 'Heatbridge' microservice
Based on feedback, the proposal is to make a heatbridge microservice which can handle the AAI update (heatbridge).
The following diagram illustrates two cases.
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)
- Either during the SO VNF adapter vfModule create or from a new BPMN workflow step, invoke the heatbridge microservice.
- 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.
- 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.
- Either during the SO VNF adapter vfModule create or from a new BPMN workflow step, invoke the heatbridge microservice.
- 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.
- 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.
Invoke SO VNF adapter to create vfModuleSO OpenStack VNF adapterSO Multicloud VNF plugin adapter
SO VNF adapter creates vfModuleSO directly interacts with the OpenStack cloudMulticloud adapter calls Multicloud which handles creating the vfModule
If vfModule was successful, new workflow step invokes new Heatbridge microserviceQuery the OpenStack cloud for informationIf 1a, 2a path was followed, the microservice communicates directly to OpenStack to query infoIf Multicloud path is being used, query Openstack via the Multicloud Openstack API
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:
As in step 3 in phase 1 above, invoke the Heatbridge microserviceIf 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).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).(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
When using the Multicloud VNF plugin adapter to instantiate more generically on various cloud types, the recommended approach (see Bin Yang 's comments) is to have Multicloud handle the AAI update as the cloud specific plugins have the best knowledge of how to communicate with the cloud plus any unique cloud specific details that may end up in AAI. This is illustrated by the following diagram.
A new BPMN workflow step (or Building Block) is added to trigger an AAI update following the step where the vfModule was created.The Multicloud VNF plugin adapter makes the call to Multicloud to perform the AAI update.The appropriate Multicloud plugin queries the relevant cloud region for workload details.The Multicloud plugin updates AAI with the workload details.Meanwhile the Multicloud plugin adapter can query Multicloud for status of the AAI update until it is complete.
Key issues to close
Multicloud infra-workload API additions to support (TBD - but perhaps something like this):Add new call to trigger Multicloud to update AAIPOST http://msb-iag.onap:80/api/multicloud/v1/{cloud-owner}/{cloud-region}/infra_workload/{workload-id}Enhance existing Multicloud query to support AAI update status (e.g. AAI_UPDATE_IN_PROGRESS, AAI_UPDATE_COMPLETED, ...)GET http://msb-iag.onap:80/api/multicloud/v1/{cloud-owner}/{cloud-region}/infra_workload/{workload-id}
The VNF API in SO between BPMN and the VNF Adapter needs a new API call (TBD):Maybe it could be a variant of the vfModule create/update API: POST/PUT {aaiVnfId}/vf-modules/{aaiVfModuleId}/
Proposed Approach - via OpenStack VNF Adapter
The SO OpenStack VNF adapter will not be replaced by the multicloud adapter in the short term, so code has been submitted for review ( https://gerrit.onap.org/r/#/c/78155/ ) to add AAI update (i.e. Heatbridge) into the SO OpenStack VNF Adapter. To align with the proposal above for AAI update when using the Multicloud VNF plugin adapter, the following diagram illustrates the proposal for the OpenStack VNF Adapter.
As with the Multicloud VNF plugin adapter, a new BPMN workflow step invokes the SO Openstack adapter to trigger the AAI update.The OpenStack VNF adapter queries the OpenStack cloud for the workload details.Update AAI with the workload details.
Key Issues to close
Add the new workflow step and update the VNF adapter API to have an AAI update API call (same/similar as needs to be done for the Multicloud plugin adapter case)Modify the above Heatbridge gerrit to work as recommended here.
PREVIOUS MATERIAL:
Preferred approach
A couple possible approaches are shown below. Approach 1 is a bit more complex and attempts to enable support for other things like auditing (assume that means comparision of AAI configuration vs actual cloud configuration). Approach 2 - based on Bin Yang comments on Approach 1 - is simpler.
The preference here is for Approach 2. Perhaps the way to go is look at auditing as another feature which will need to be supported by Multicloud.
Approach 1
Following is a proposal for how the functionality could be done.
Step 1 (referring to diagram above)
In this step, a new SO workflow step makes a call to query the details about a workload. Based on details in SO's cloud site DB, a choice will be made to invoke 2a or 2b
Step 2a
This gerrit ( https://gerrit.onap.org/r/#/c/78155/ ) proposes a code change to perform Openstack specific AAI Workload Update functionality within the SO openstack adapter implementation. In this path, the workload detail query is handled by this code in SO.
Step 2b
Alternatively, for cloud sites that are set up to talk to Multicloud, the workload detail query is sent to Multicloud via an API (see below for more details). Multicloud has plugins for various cloud types, so the appropriate plugin will be selected to perform the query.
Step 3
The workload detail query result is returned. Regardless of path or cloud type, the detail is returned in a normalized format. Suggest this be in conformance with the AAI schema.
Step 4
The workload detail results can be passed along the workflow to the next step which performs the update to AAI. (other uses can be supported by separating query from AAI update, such as auditing)
Step 5
Perform the actual update to AAI. Logic could be supported in the workflow to determine whether this step must be performed and whether failure affects the success of the workload creation or not.
Notes on updates to the Multicloud API
The SO-MC infrastructure GET API (https://onap.readthedocs.io/en/casablanca/submodules/multicloud/framework.git/docs/specs/multicloud_infra_workload.html) needs to be extended to include the workload query details
GET http://msb-iag.onap:80/api/multicloud/v1/<cloud-owner>/<cloud-region>/infra_workload/<workload-id>add the workload details to the responseOr, since it's probably time consuming/expensive to query the workload details, maybe it's better to add a new query to the APIWhat's best?GET http://msb-iag.onap:80/api/multicloud/v1/<cloud-owner>/<cloud-region>/infra_workload/<workload-id>?depth=allGET http://msb-iag.onap:80/api/multicloud/v1/<cloud-owner>/<cloud-region>/infra_workload_details/<workload-id>GET http://msb-iag.onap:80/api/multicloud/v1/<cloud-owner>/<cloud-region>/infra_workload/<workload-id>/detailssomething else?
Approach 2
Here is another variation - taking into account Bin Yang's comments.
Along the 2b-3b sequence, SO invokes via a POST to Multicloud to trigger an AAI Update. SO can invoke a GET along step 6 to query the status of the AAI Update.
Note, in this approach AAI update is either performed via sequence 1,2a,3a,4a using SO Openstack adapter. Or, via sequence 1, 2b, 3b, 4b, 5, 6 using SO Multicloud adapter.
Other points
In addition to creating the workload details in AAI, there will need to be corresponding delete and update functions as well.
4 Comments
Bin Yang
I have concerns as below:
My suggestion is:
1, offload the updating to multicloud which expose API to SO for triggering such updating:
At step 1, SO request MultiCloud to update AAI (not to query workload detail) : parameter: workload-id
Add new operation to existing API for this purpose:
POST /api/multicloud/v1/{cloud-owner}/{cloud-region-id}/infra_workload/{workload-id}
At step 3, MultiCloud return/ack SO the updating has started with progress stage: Inventory updating/updated. SO could query the progress by reusing the existing API:
GET /api/multicloud/v1/{cloud-owner}/{cloud-region-id}/infra_workload/{workload-id}
Which will return the status of infra_workload and inventory updating.
At step 5, MultiCloud (not SO) will update AAI with workload details according to the AAI schema
Please let me know if this works for your purpose . Thanks
Habib Torab
What is the status of this? Is the automation for HeatBridge getting implemented in Dublin?
Aniello Paolo Malinconico
I think in Dublin, it has not been integrated as an SO component but it still is a robot script. Isn't it?
Eric Multanen
See Code which performs AAI Update (HeatBridge) for notes on some testing/investigaiton I did with Dublin.