...
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'.
Approach 1
Following is a proposal for how the functionality could be done.
...
- GET http://msb-iag.onap:80/api/multicloud/v1/<cloud-owner>/<cloud-region>/infra_workload/<workload-id>
- add the workload details to the response
- Or, since it's probably time consuming/expensive to query the workload details, maybe it's better to add a new query to the API
- What's best?
- GET http://msb-iag.onap:80/api/multicloud/v1/<cloud-owner>/<cloud-region>/infra_workload/<workload-id>?depth=all
- GET 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>/details
- something 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.
...