In Dublin timeframe, the plan is VF packages will still be onboarded as Heat zip files.  Cloud artifact files (with newly defined types) will be added to the package.

SO multicloud adapter will still invoke Multicloud with a ‘template_type’ of ‘heat’ and fill in a ‘template_data’ section for Heat (as in Casablanca).  In Multicloud, based on the cloud type of the cloud region, the request may be handled by a Multicloud plugin that will expect to deploy using the cloud artifact files instead of Heat (e.g. K8S).  In these non-Openstack plugin cases the Heat ‘template_data’ content is ignored and the other parameters and associated cloud artifacts are used exclusively.


Outline of the proposed changes (in bold):


POST  http://{msb IP}:{msb port}/api/multicloud/v1/{cloud-owner}/{cloud-region-id}/infra_workload











   "template_data":{ … }



The ‘vf-module-model-*-id’s will be used by the Multicloud plugin to retrieve the associated cloud artifacts.  It will be the job of the SDC client in Multicloud to download the artifacts and make an association between the model IDs and the artifacts during SDC distribution.


QUESTION:  What is the purpose of the ‘generic-vnf-id’ and ‘vf-module-id’ parameters?  I initially was thinking multicloud could use these to query AAI for the model-customization-id, but since SO has it already, it can send and avoid the extra AAI lookup.  So, is there another use of ‘generic-vnf-id’ and ‘vf-module-id’ ? 

ANSWER: they were put there for heatbridge and metadata purposes (not for model information lookup).


‘user_directives’ is new and ‘sdnc_directives’ was in the API before but not used.  Both will have a format similar to the following:


 "sdnc_directives": {
    "attributes": [
        "attribute_name": "public_net_id",
        "attribute_value": "external"
        "attribute_name": "vnf_id",
        "attribute_value": "222c8b04-07b9-43aa-bea8-0a6aade3cf45"
        "attribute_name": "vf_module_id",
        "attribute_value": "78165ab6-264d-4e32-abe7-72936b893086"
        "attribute_name": "vfw_image_name",
        "attribute_value": "ubuntu-16.04"


SO will need to populate these two directives attributes based on SDNC assignments and SO UserParams.


Secondly, we can start thinking about the API to support the AAI Update function (aka heatbridge).

Take a look at this page: for thoughts on this topic.

Basically,  Multicloud will have an API to query workload details and it will respond with a normalized data (to AAI schema) that can then be used for auditing or AAI update.

  • No labels


  1. The enhancement of existing API could be done by having new fields as either an optional field for API v1, and mandatory field for API v2 (v2 will not happen soon)

  2. suppose such field   "model-customization-id":"<uuid>", is used to as an indication to multicloud, which will leverage such one to fetch all the needed artifacts.

    if so, we may change it to model-version-id.

    btw, what's the usage of such "model-customization-id"? is it related to artifacts like HEAT/HEAT_ENV?