Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 encourage):encouraged):


  1. Usage / Updates to the Multicloud API 
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-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
      serverONAP JIRA
      serverId425b2b0a-557c-3c0c-b515-579789cceedb
      keySO-1442
    4. Added to the Multicloud API will be a 'user_directives' parameter.  SO will fill in with parameters passed in the userParams. 
      Jira
      serverONAP JIRA
      serverId425b2b0a-557c-3c0c-b515-579789cceedb
      keySO-1443
    5. For more details see:  SO to Multicloud API enhancements
  2. Use of SO cloud site DB 
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-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
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-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)
  8. 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
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-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

    Authentication between SO and Multicloud 
    1. Jira
      serverONAP JIRA
      serverId425b2b0a-557c-3c0c-b515-579789cceedb
      keySO-
    1450
    1. Current communication between SO and Multicloud is not authenticated
  12. Update of AAI post creation of VF modules  
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-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)
    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.
  13. Usage / Updates to the Multicloud API 

    Authentication between SO and Multicloud 

    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-

    1446

    1450

  14. SO passes 'oof_directives' - info it receives from OOF - along to Multicloud
    1. Current communication between SO and Multicloud is not authenticated
  15. Other enhancements

  16. The API also has an 'sdnc_directives' parameter - how this is filled out and format should be defined 
    1. Jira
      serverONAP JIRA
      serverId425b2b0a-557c-3c0c-b515-579789cceedb
      keySO-

  17. 1442
  18. There has been discussion of a 'user_directives' parameter - how this is provided and format should be defined - and added to the API 
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-1443
    1. 1449
      1. Need to understand the use case for this.  Nice to have ?
  19. Other  LCM items

    1. Does the Multicloud API need enhancement for other LCM actions that SO participates in? e.g. Scale out, …. ?
  20. 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
  21. See:  SO to Multicloud API enhancements
  22. Distribution of cloud artifacts 
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-1441
    1. Current thought is that no work will be required for this item.
  1. Other misc enhancements

  2. Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-1448
  3. JiraserverONAP JIRAserverId425b2b0a-557c-3c0c-b515-579789cceedbkeySO-1449