...
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 - 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.
| Note | ||
|---|---|---|
| ||
|
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.
| Note | ||
|---|---|---|
| ||
|
PREVIOUS MATERIAL:
| Note | ||
|---|---|---|
| ||
|
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.
...