Versions Compared

Key

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

...

  1. Use of SO cloud site DB 
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-1447

    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. 
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-1445

    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 
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-1450

    1. Current communication between SO and Multicloud is not authenticated
  6. 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)
  7. Usage / Updates to the Multicloud API 
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-1446

    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 
      Jira
      serverONAP JIRA
      serverId425b2b0a-557c-3c0c-b515-579789cceedb
      keySO-1442
    3. 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
    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.
    5. Seems like multicloud could get the template files directly via SDC distribution
    6. And other parameters can be passed in generically via the directives parameters mentioned just above.
    7. See:  SO to Multicloud API enhancements
  8. Distribution of cloud artifacts 
    Jira
    serverONAP JIRA
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keySO-1441

    1. Current thought is no work will be required for this item.
  9. Other misc enhancements

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