Page Comparison

...

Support for Kubernetes based cloud regions is a specific target of an additional cloud region type.  See:  https://wikilf-onap.onapatlassian.orgnet/wiki/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 encourage):encouraged):

1. Usage / Updates to the Multicloud API 

   Jira Legacy
   server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 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 Legacy
      server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 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 Legacy
      server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key SO-1443

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

2. Use of SO cloud site DB 

   Jira Legacy
   server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 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

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/CloudRegionMake 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. 

4. Update of AAI post creation of VF modules  

   Jira Legacy
   server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 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)

5. Volume groups, Networks, etc. 

   Jira Legacy
   server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 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 ?

6. Other  LCM items

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

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

   1. Jira Legacy
      server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key SO-

   1450
1. Current communication between SO and Multicloud is not authenticated

8. Update of AAI post creation of VF modules  

   Jira Legacy
   server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key SO-1444

1. What needs to be done generically for many different generic cloud type  - heatbridge sounds very openstack specific
2. See: Proposal for generic AAI Workload Update (aka heatbridge)
9. Usage / Updates to the Multicloud API 

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

10. Authentication between SO and Multicloud 

    Jira Legacy
    server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key SO-

    1446

    1450

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 Current communication between SO and Multicloud is not authenticated

11. Other enhancements

    1. Jira Legacy
       server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key SO-

1442
12. There has been discussion of a 'user_directives' parameter - how this is provided and format should be defined - and added to the API 

    Jira Legacy
    server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key SO-1443

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

15. 1. 1449

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

16. Other  LCM items

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

17. 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
18. Distribution of cloud artifacts 

    Jira Legacy
    server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key SO-1441

    Other misc enhancements

19. Jira Legacy
    server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key SO-1448

Jira LegacyserverSystem JiraserverId4733707d-2057-3a0f-ae5e-4fd8aff50176keySO-1449

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