SO to Multicloud API enhancements

Owned by Eric Multanen
Last updated: Feb 22, 2019
2 min read

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

{

   "generic-vnf-id":"<generic-vnf-id>",

   "vf-module-id":"<vf-module-id>",

   "vf-module-model-invariant-id":"<uuid>"

   "vf-module-model-version-id":"<uuid>",

   "vf-module-model-customization-id":"<uuid>",

   "oof_directives":{},

   "sdnc_directives":{},

   "user_directives":{},

   "template_type":"heat”,

   "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:  https://lf-onap.atlassian.net/wiki/pages/viewpage.action?pageId=16350907 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.