Proposal for generic AAI Workload Update (aka heatbridge)

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

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.