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

 

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


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

    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  SO-1442 - Getting issue details... STATUS
    4. Added to the Multicloud API will be a 'user_directives' parameter.  SO will fill in with parameters passed in the userParams.  SO-1443 - Getting issue details... STATUS
    5. For more details see:  SO to Multicloud API enhancements

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

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

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

    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)

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

    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 ?

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

    1. SO-1448 - Getting issue details... STATUS
      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.

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

    1. Current communication between SO and Multicloud is not authenticated

  7. Other enhancements

    1. SO-1449 - Getting issue details... STATUS
      1. Need to understand the use case for this.  Nice to have ?

  8. Other  LCM items

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

  9. 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
  10. Distribution of cloud artifacts  SO-1441 - Getting issue details... STATUS
    1. Current thought is that no work will be required for this item.
  • No labels