Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

SO Multicloud Adapter in Casablanca

In Casablanca, a multicloud adapter was added to the SO Openstack adapter component.  This adapter was developed based on SO's VnfPluginAdapter and uses the Version 2 of SO's VNF Adapter REST API.  This is configured for use by ensuring the BPMN component configmap has the vnf rest endpoint set to v2.

For example, once SO has been deployed, updating the bpmn config map will change the REST API version used:

Difference after changing with: kubectl -n onap edit configmap dev-so-so-bpmn-infra-app-configmap 
         vnf:
           endpoint: http://so-openstack-adapter.onap:8087/services/VnfAdapter
           rest:
-            endpoint: http://so-openstack-adapter.onap:8087/services/rest/v1/vnfs
+            endpoint: http://so-openstack-adapter.onap:8087/services/rest/v2/vnfs
         volume-groups:
           rest:
             endpoint: http://so-openstack-adapter.onapg:8087/services/rest/v1/volume-groups


On the Multicloud side, the Infrastructure workload LCM API of the v1 Rest specification is what is supported by this new SO multicloud adapter.

Specifically, this section:  https://onap.readthedocs.io/en/casablanca/submodules/multicloud/framework.git/docs/MultiCloud-APIv1-Specification.html#infrastructure-workload-lcm

The SO Multicloud adapter supports the POST, GET and DELETE described in that section.

In Casablanca, the new multicloud adapter was derived from SO adapter code that was oriented to Openstack/Heat and it was only tested with Heat based examples (e.g. vFW), so some refinements are expected.


For Dublin and beyond

In Dublin time frame, we are looking at improving the multicloud adapter to be able to support multiple cloud types in a generic way SO-1353 - Getting issue details... STATUS .

Support for Kubernetes based cloud regions is a specific target of an additional cloud region type.  See:  https://wiki.onap.org/display/DW/K8S+based+Cloud+Region+Support

 

Following is a list of topics which fall under either new features or enhancements that will be needed (comment, discussion, questions are encourage):


  1. Use of SO cloud site DB  SO-1447 - Getting issue details... STATUS

    1. In the current usage, the multicloud adapter still uses a separate record in SO's cloud site DB for each cloud region (also uses just cloud-region not the cloud_owner + cloud_region yet)
    2. It seems that there really would only need to be a single entry or other configuration to identify the multicloud endpoint. 

  2. Multicloud plugin type

    1. The endpoint to talk to multicloud currently needs to specify the plugin type as part of the URL
    2. e.g. http://msb-iag.onap:80/api/multicloud-titaniumcloud/v1/CloudOwner/CloudRegion/infra_workload
    3. It seems like there could just be a single endpoint e.g. http://msb-iag.onap:80/api/multicloud/v1/CloudOwner/CloudRegion/infra_workload
    4. And multicloud could determine and use the correct plugin based on the type of cloud residing at CloudOwner/CloudRegion

  3. Volume groups, Networks, etc.  SO-1445 - Getting issue details... STATUS

    1. Current testing / usage of the multicloud plugin has only touched single heat template based VNFs (e.g. vFW)
    2. Support for volume groups, networks, and anything else (e.g. nested heat templates?) should be evaluated
    3. What changes / enhancements are required to the Multicloud API ?
    4. Are these concepts applicable generically to multiple types of clouds ?

  4. Other  LCM items

    1. Does the Multicloud API need enhancement for other LCM actions that SO participates in? e.g. Scale out, …. ?

  5. Authentication between SO and Multicloud  SO-1450 - Getting issue details... STATUS

    1. Current communication between SO and Multicloud is not authenticated

  6. Update of AAI post creation of VF modules   SO-1444 - Getting issue details... STATUS

    1. Heatbridge -what is it? (there's a to a python script in the SO code, robot scripts have some kind of heatbridge funciton too)
    2. Current multicloud adapter testing has not utilized heatbridge
    3. What needs to be done generically for many different generic cloud type  - heatbridge sounds very openstack specific

  7. Usage / Updates to the Multicloud API  SO-1446 - Getting issue details... STATUS

    1. SO passes 'oof_directives' - info it receives from OOF - along to Multicloud
    2. The API also has an 'sdnc_directives' parameter - how this is filled out and format should be defined  SO-1442 - Getting issue details... STATUS
    3. There has been discussion of a 'user_directives' parameter - how this is provided and format should be defined - and added to the API  SO-1443 - Getting issue details... STATUS
    4. 'template_type' and 'template_data' - are these required?  Currently, for heat, we pass a stack object, which mainly has the parameter list and the heat template and other files.
      1. Seems like multicloud could get the template files directly via SDC distribution
      2. And other parameters can be passed in generically via the directives parameters mentioned just above.

  8. Distribution of cloud artifacts  SO-1441 - Getting issue details... STATUS

  9. Other misc enhancements

    1. SO-1448 - Getting issue details... STATUS
    2. SO-1449 - Getting issue details... STATUS
  • No labels