Architecture Updates

• OpenStack Pike plugin
  New plugin to adapt OpenStack Pike to ONAP

• OpenStack plugin, Titanium Cloud plugin, VIO plugin
  integration with SO with new API: Infrastructure Workload LCM

  
  

• K8S plugin
  New plugin, to adapt k8s cluster to ONAP
  PoC, Not be part of Casablanca Release

  
  

• Azure plugin
  New plugin, to adapt azure cloud to ONAP
  PoC, Not be part of Casablanca Release

S3P

• Secured communication:
  Leverage MSB and OOM with ISTIO
  
  
• RBAC
  Leverage MSB and OOM with ISTIO
  
  
• Logging
  Onappylog for python 3

Edge automation support

• Automation of the on-boarding multiple cloud regions
  Leverage the multi-region feature of OpenStack
  On-board one openstack region, multicloud plugin for OpenStack will automate the on-boarding of other openstack regions

Enhance for automated Close loop Control

• Update the AAI with created heat stack resource
  Coupled with the integration of SO and Multicloud for HEAT based VNF
  MultiCloud plugin will update the AAI with the created heat stack resource
  MultiCloud will also associate the AAI’s heat stack resource with generic VNF and VF Module objects
  These steps have been done via robot heatbridge script in previous releases, which is not an pure automated way.

API version upgrading

• Align to the ONAP functional requirement
  Consistent ID of a cloud region
  Replace the {vimid} with {cloud-owner}/{cloud-region-id}
  Design spec: https://gerrit.onap.org/r/#/c/56671
  
  
• Existing API v0:
  http(s)://{service IP}:{service port}/api/multicloud/v0/{vimid}/
  
  
• Proposed API v1:
  http(s)://{service IP}:{service port}/api/multicloud/v1/{cloud-owner}/{cloud-region-id}/
  
  
• Impacts:
  All multicloud components
  Each components to expose API v1, while continue to maintain the API v0
  Azure plugin and k8s plugin might go with API v0 for now, since they will not be part of Casablanca Release.
  SO/VFC/OOF/APPC have the choice to continue with API v0, or change to API v1

VM action APIs for VFC

• MultiCloud has been exposing a set of APIs to VFC
  Abstract from OpenStack API which was defined during OPEN-O community
  Backward compatibility to keep maintain this API set
  VF-C continues to use this set of API in Casablanca Release

• VF-C requests to extend this API set to support VM action for healing use case
  Start server
  Stop server
  Restart server

• API spec:
  Spec: https://gerrit.onap.org/r/#/c/60671/2/docs/MultiCloud-APIv1-Specification.rst
  For API v0: msb.onap.org:80/api/multicloud/v0/{vimid}/{tenantid}/servers/{serverid}/action
  For API v1: msb.onap.org:80/api/multicloud/v1/{cloud-owner}/{cloud-region-id}/{tenantid}/servers/{serverid}/action

Infrastructure Workload LCM API for SO

• The integration of SO/MultiCloud can be provisioned manually for ONAP Amsterdam and Beijing Release
  Leveraging the MultiCloud proxy of heat stack APIs.
  
  
• The integration of SO/MultiCloud serves multiple purposes:

1. Centralized representation of cloud regions:The ID of a cloud region will be specified by either VID or OOF, SO will not need to access the representation of a cloud region since it offload it to MultiCloud
2. Offloading the updating the Infrastructure workload template (HEAT) parameters: 
   1. SO consults both SDNC and OOF for the proper heat parameters specific to a VF module to be instantiated
   2. SO have to update the heat template before issue the API call to OpenStack without integration of MultiCloud 
   3. With Integration SO could offload it to MultiCloud which should be more appropriate for decompose the workload template and updating with new parameters.
3. Cloud Agnostic Intent realization
   1. ONAP users specify the Cloud Agnostic Intent policy
   2. OOF match the policy to the specifc cloud regions, return the “Cloud Agnostic Intent” to SO, SO will pass it to MultiCloud
   3. MultiCloud will realize the Cloud Agnostic Intent

• Workflow
  https://wiki.onap.org/display/DW/SO+Casablanca+HPA+Design
  
  
• API description
  • API spec:  https://gerrit.onap.org/r/#/c/60691
  • API for workload instantiation: 
    • POST http://{msb IP}:{msb port}/api/multicloud /v1/{cloud-owner}/{cloud-region-id}/infra_workload
      Request body:
      { "generic-vnf-id":"<generic-vnf-id>", "vf-module-id":"<vf-module-id>", "oof_directives":{}, "sdnc_directives":{}, "template_type":"<heat/tosca/etc.>", "template_data":{} }
      Response Code:
      Success  201 - Created  Resource was created and is ready to use.
      Error 
      • 400 - Bad Request  Some content in the request was invalid.
      • 401 - Unauthorized  User must authenticate before making a request.
      • 409 - Conflict  This operation conflicted with another operation on this resource.
    • Response body:
      {“workload_id”,”<stack id for openstack heat stack>”}
  • API for workload query:
    •  GET http://{msb IP}:{msb port}/api/multicloud /v1/{cloud-owner}/{cloud-region-id}/infra_workload/{workload_id}
    • Request body: N/A
    • Response Code:
      • Success 
        • 200 - Success  Resource is avalable.
      • Error
        • 400 - Bad Request  Some content in the request was invalid.
        • 401 - Unauthorized  User must authenticate before making a request.
        • 404 - Not found
        • 500 - Internal error
    • Response body:
    • {“workload_status":“<stack status>“}
  • API for workload termination: 
    • DELETE http://{msb IP}:{msb port}/api/multicloud /v1/{cloud-owner}/{cloud-region-id}/infra_workload/{workload_id}
    • Request body: N/A
    • Response Code:
      • Success 
        • •204 - No content  The server has fulfilled the request by deleting the resource.
      • Error
        • 400 - Bad Request  Some content in the request was invalid.
        • 401 - Unauthorized  User must authenticate before making a request.
        • 404 - Not found
        • 500 - Internal error
    • Response body:
      • N/A
• Notes
  • “generic-vnf-id”/”vf-module-id” is used to update AAI with infrastructure’s workload resource and associate them with AAI generic vnf/VF module objects
  • “oof_directive” is the output of OOF which can be consumed by either VFC or MultiCloud for updating the parameters of the heat template (e.g. the updating of flavor id to realize the HPA requirements)
  • “sdnc_directives“ is the output of SDNC which is also to update the parameters of heat templates
  • This updating of heat template parameters is done by SO right now, it can be offloaded to MultiCloud by passing SDNC parameters to MultiCloud
  • “template_type” is to enable the expanding of this API to support other cloud specific artifacts, e.g. helm chart (or k8s specific tosca template) for k8s plugin, arm template (or azure specific tosca template) for azure plugin, etc. 
  • “template_data” varies along with “template_type”
  • It follows the OpenStack heat API while the {“template_type” : “heat”}
  • It is to be discussed how to define the schema of template_data for other template_type.
• Example for HEAT based template
  • POST http://{msb IP}:{msb port}/api/multicloud /v1/{cloud-owner}/{cloud-region-id}/infra_workload 
    { "generic-vnf-id":"<generic-vnf-id>", "vf-module-id":"<vf-module-id>",  "oof_directives":{"directives":[{ "id":"<ID of VNFC>", "type": "vnfc", "directives":[ { "type":"flavor_directive", "attributes":[ {"attribute_name":"flavor", "attribute_value":"f.medium.hpa1"}]}]}]}, "sdnc_directives":{},  "template_type":"heat", "template_data":{  "files":{  },     "disable_rollback":true,     "parameters":{ "flavor":"m1.heat" }, "stack_name":"teststack",  "template":{ "heat_template_version":"2013-05-23",        "description":"Simple template to test heat commands",    "parameters": {  "flavor":{ "default":"m1.tiny", "type":"string"}},     "resources":{"hello_world":{ "type":"OS::Nova::Server", "properties":{                "key_name":"heat_key", "flavor":{"get_param":"flavor" },             "image":"40be8d1a-3eb9-40de-8abd-43237517384f",             "user_data":"#!/bin/bash -xv\necho \"hello world\" &gt; /root/hello-world.txt\n“} } } }, "timeout_mins":60  } }}

Cost evaluation API for OOF

• Proposal
  • Besides the capacity check support to OOF, MultiCloud could also support OOF by evaluating the cost to place the workload to a specific cloud region
• Value propositon
  • The evaluation of cost can be very dynamic which cannot be handled by static data source
  • Some Infrastructure’s vendor is not willing to expose their internal information to AAI especially with regarding to cost evaluation
  • The way to evaluate the cost could vary from one type of infrastructure to another type, from one stack to another stack.
  • The fact that MultiCloud plugins adapt ONAP to each type of infrastructure offers the chance to encapsulate the cost evaluation and return a net value to OOF which simplies the OOF’s logic
• Progress
  • OOF/SO/MC teams had several round of discussion and get consensus on the overall workflow.
  • How it can be realized by MultiCloud is to be further discussed.
  • The detail of API spec is to be further refined.
  • https://wiki.onap.org/display/DW/Backup+***+Edge+Scoping+MVP+for+Casablanca+-+ONAP+Enhancements+***+Backup
• API spec: N/A , not scope of Casablanca
  • URI: POST http://{msb ip}:{msb port}/api/multicloud/v1/cost_evaluation
  • Request Body:[    {"cloud-owner": "owner1", "cloud-region-id": "region1", "directives":[]    },    {"cloud-owner": "owner2",  "cloud-region-id": "region2", "directives": []  }]
  • Response: [   {     "cloud-owner": "owner1",  "cloud-region-id": "region1",  "net-value": 100    },  {   "cloud-owner": "owner2", "cloud-region-id": "region2",  "net-value": 101    }]