Versions Compared

Version Old Version 4 New Version 5
Changes made by

Eric Multanen (Deactivated)

Eric Multanen (Deactivated)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 microservice which can handle the AAI update (heatbridge).

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 Added

  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 Added

  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).


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.

Image Modified

  1. A new BPMN workflow step (or Building Block) is added to trigger an AAI update following the step where the vfModule was created.
  2. The Multicloud VNF plugin adapter makes the call to Multicloud to perform the AAI update.
  3. The appropriate Multicloud plugin queries the relevant cloud region for workload details.
  4. The Multicloud plugin updates AAI with the workload details.
  5. Meanwhile the Multicloud plugin adapter can query Multicloud for status of the AAI update until it is complete.


Note
titleKey issues to close



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.

Image Modified

  1. As with the Multicloud VNF plugin adapter, a new BPMN workflow step invokes the SO Openstack adapter to trigger the AAI update.
  2. The OpenStack VNF adapter queries the OpenStack cloud for the workload details.
  3. Update AAI with the workload details.


Note
titleKey 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:

Note
titlePreferred 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.

...