Multi-VIM/Cloud Casablanca Architecture Review

Owned by Bin Yang
Last updated: Aug 21, 2018
4 min read



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



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

  • 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    }]