Page History

...

In Dublin time frame, we are looking at improving the multicloud adapter to be able to support multiple cloud types in a generic way (https://jira.onap.org/browse/SO-1353)

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

Onboarded VNF packages

VNFs will be onboarded in SDC as Heat packages.  Added to the package will be artifacts with some new types - something like: CLOUD_TECHNOLOGY_DESCRIPTION, CLOUD_TECHNOLOGY_CONFIG_PROFILES.

JIRA reference: https://jira.onap.org/browse/SDC-2041

The Heat artifacts of the package are effectively ignored and the actual VF workload is defined in the new CLOUD_TECHNOLOGY_* artifacts.  These will be passed opaquely through from SDC to Multicloud when services designed with VFs created from these packages are distributed.   The use of the heat packaging is a near term convenience to allow support of other cloud types to be supported by Multicloud while minimizing required changes to SDC and SO.

SO Modifications

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

1. Usage / Updates to the Multicloud API 

   Jira
   server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-1446

   1. The SO VNF plugin adapter will invoke the multicloud plugin (based on the cloud site) and call Multicloud to instantiate workloads (e.g. vf modules).  Added to the Multicloud will be the vf module model identifiers to allow Multicloud to gather the CLOUD_TECHNOLOGY_* artifacts (which Multicloud will have downloaded during SDC distribution).
   2. As in Casablanca, SO passes 'oof_directives' - info it receives from OOF - along to Multicloud.  This provides relevant policy based parameters to be passed along. 
   3. The API also has an 'sdnc_directives' parameter.  New for Dublin, this will be filled in with the SDNC provided parameters 

      Jira
      server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-1442

   4. Added to the Multicloud API will be a 'user_directives' parameter.  SO will fill in with parameters passed in the userParams. 

      Jira
      server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-1443

   5. For more details see:  SO to Multicloud API enhancements

2. Use of SO cloud site

   DB

   DB 

   Jira
   server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-1447

1. In the current (Casablanca) usage, the multicloud plugin adapter still uses a separate record in SO's cloud site and identity 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. 

3. Multicloud plugin type

4. The endpoint to talk to multicloud currently needs to specify the plugin type as part of the URL
5. e.g. http://msb-iag.onap:80/api/multicloud-titaniumcloud/v1/CloudOwner/CloudRegion/infra_workload
6. It seems like there could just be a single endpoint e.g. http://msb-iag.onap:80/api/multicloud/v1/CloudOwner/CloudRegion/infra_workload
1. Make changes so that there is one identity record for Multicloud which is referenced by the SO cloud site entries that will make use of the Multicloud vnf plugin. 

7. Update of AAI post creation of VF modules  

   Jira
   server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-1444

   1. Long term plan is that Multicloud will handle the AAI update function.  How much will get implemented in Multicloud in Dublin is TBD.
   2. As described more in the details page, there is code for the Openstack implementation of Heatbridge for SO.  It would be ideal for Dublin to, at minimum, get the usage of that new functionality to be invoked by a separate workflow.
   3. For more details see: Proposal for generic AAI Workload Update (aka heatbridge)
And multicloud could determine and use the correct plugin based on the type of cloud residing at CloudOwner/CloudRegion

9. Volume groups, Networks, etc. 

   Jira
   server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-1445

1. In Casablanca, the multicloud vnf plugin does not contain any logic for handling volume groups.
2. If appropriate, the multicloud vnf plugin should add that support
3. Current testing / usage of the multicloud plugin has only touched single heat template based VNFs (e.g. vFW)
4. Support for volume groups, networks, and anything else (e.g. nested heat templates?) should be evaluated
5. What changes / enhancements are required to the Multicloud API ?
6. Are these concepts applicable generically to multiple types of clouds ?

10. Other  LCM items

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

11. Plan for which vnf adapter to use / how to select the right one

    1. Jira
       server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-1448

       1. This refers to the fact that the Openstack vnf adapter uses the v1 vnf adapter API and the vnf plugin adapter uses the v2 vnf adapter API.
       2. The idea is that maybe some cloud sites need to be supported by multicloud vnf plugin adapter, but other sites should be supported with the openstack vnf adapter.
       3. Several approaches come to mind:
          1. Support v1 and v2 adapter API - openstack and vnfplugin adapters- select based on some entry in cloud site
          2. Long term, vnfplugin adapter is goal - openstack and multicloud plugins, deprecate openstack adapter - short term, continue to configure to use either v1 (default) or v2
          1. How to verify openstack path of vnfplugin is on par with legacy openstack adapter (i.e. no bugs, corner cases, etc.)
          2. another variation - use multicloud for openstack as well - but again, functionality needs to be on par with the legacy (e.g. volume groups, ...)
          3. Update openstack adapter to use v2 api as well - allow either openstack adapter or vnfplugin adapter to be selected based on cloud site info.

12. Authentication between SO and Multicloud 

    Jira
    server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-1450

    Authentication between SO and Multicloud

1. Current communication between SO and Multicloud is not authenticated

13. Other enhancements

    1. Jira
       server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-1449

       1. Need to understand the use case for this.  Nice to have ?

14. Other  LCM items

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

15. 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
16. Distribution of cloud artifacts 

    Jira
    server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key SO-1441

1. 1. Current thought is that no work will be required for this item

2. Update of AAI post creation of VF modules

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

3. Usage / Updates to the Multicloud API

4. SO passes 'oof_directives' - info it receives from OOF - along to Multicloud
5. The API also has an 'sdnc_directives' parameter - how this is filled out and format should be defined
6. There has been discussion of a 'user_directives' parameter - how this is provided and format should be defined - and added to the API
7. '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.
8. Seems like multicloud could get the template files directly via SDC distribution
And other parameters can be passed in generically via the directives parameters mentioned just above
9. 1. .