Page History

...

Improve "workload deployability" by avoiding exposure of "cloud specific" capabilities to several ONAP components and addressing "separation of concerns"
Support capacity check (besides capability check) for HPA resources
Applicable to all workloads - VM-based or Container-based

...

Code Block

language	py
theme	Emacs
title	OOF Homing Enhanced Cloud Selection Policy Example (Step 2a)
linenumbers	true
collapse	true

#
#Spec Reference: https://wiki.onap.org/display/DW/Edge+Scoping+MVP+for+Casablanca+-+ONAP+Enhancements#EdgeScopingMVPforCasablanca-ONAPEnhancements-Cloud-agnosticPlacement/Networking&HomingPolicies(Phase1-CasablancaMVP,Phase2-StretchGoal)
#

from jsonschema import validate

oof_cloud_selection_policy_schema = {
        "service": {"type": "string"},
        "policyName": {"type": "string"},
        "policyDescription": {"type": "string"},
        "templateVersion": {"type": "string"},
        "version": {"type": "string"},
        "priority": {"type": "string"},
        "riskType": {"type": "string"},
        "riskLevel": {"type": "string"},
        "guard": {"type": "string"},

        "content": {
                "type": "object",
                "required": ["cloud-cost-evaluation", "cloud-deployment-intent"],
                "properties" : {

                        # VNFC is not used in the OOF->MC path for R3
                        # This is kept to be consistent with the SO-> MC path
            			# As an example, vDNS VNF in ONAP has 3 VNFCs - DNS, Packet Gen & Load Balancer --
						# Each of the VNFCs could have different policies              													      									
                        "vnfc": {"type": "string"},

                        # evaluate cloud cost if set
                        # cost is fixed per cloud type for all workloads -- simplifying assumption for R3
                        # cost specified in the respective plugin through a configuration file
                        "cloud-cost-evaluation" : {"type" : "boolean"},

                        # cloud-specific realization of the specified deployment intent
                        # happens in  multi-cloud in the cloud-specific plugin
                        "cloud-deployment-intent": {
                                "type": "object",
                                "properties" : {

                                        # Cloud Type -- Azure, K8S, OpenStack, VMware VIO, Wind River Titanium
                    					# Optionally Accomodate policies per Cloud Type
                    					# Optionally Accomodate policies per Cloud Owner & Cloud Region
                                        "Cloud Type (Cloud Provider)": {"type", "array"},
                                        "Cloud Owner & Cloud Region (VIM id)": {"type", "array"},

                                        "Infrastructure High Availability for VNF": {"type", "boolean"},

                                        "Infrastructure Resource Isolation for VNF": {"type", "string"},

                                        # Infrastructure Resource Isolation for VNF
                                        # Only certain pre-defined over-subscription values are allowed to
                                        # reflect practical deployment and simplify implementation for R3
                                        "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": {"type": "int"},
                                },
                        },
                },
        },

        "resources": {"type", "array"}, #"vgw" is also interchangeably used as "vg"
        "applicableResources": {"type", "string"},
        "identity": {"type", "string"},
        "policyScope": {"type", "array"},
        "policyType": {"type", "string"}
}

#
#Example 1: vCPE, Burstable QoS
#vCPE: Infrastructure Resource Isolation for VNF with Burstable QoS
#
oof_cloud_selection_policy_instance1 = {
        "service": "cloudSelectionPolicy",
        "policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vCPE_VNF",
        "policyDescription": "Cloud Selection Policy for vCPE VNFs",
        "templateVersion": "0.0.1",
        "version": "oofMulti-cloudCasablanca",
        "priority": "3",
        "riskType": "test",
        "riskLevel": "2",
        "guard": "False",

        "content": {
                "vnfc": "vgw",
                "cloud-cost-evaluation": True,
                "cloud-deployment-intent": {
                        "Cloud Type (Cloud Provider)": {"VMware VIO"},
            			"Infrastructure Resource Isolation for VNF": "Burstable QoS",
            			"Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": 25,

                },
        },

        "resources": ["vgw"], #"vgw" is also interchangeably used as "vg"
        "applicableResources": "any",
        "identity": "cloud-atrributes",
        "policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vgw", "vgmux"],
        "policyType": "AllPolicy"
}

#
#Example 2:
#vCPE: Infrastructure Resource Isolation for VNF with Guaranteed QoS
#
oof_cloud_selection_policy_instance2 = {
        "service": "cloudSelectionPolicy",
        "policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vCPE_VNF",
        "policyDescription": "Cloud Selection Policy for vCPE VNFs",
        "templateVersion": "0.0.1",
        "version": "oofMulti-cloudCasablanca",
        "priority": "3",
        "riskType": "test",
        "riskLevel": "2",
        "guard": "False",

        "content": {
                "vnfc": "vgw",
                "cloud-cost-evaluation": True,
                "cloud-deployment-intent": {
                 	       	"Infrastructure Resource Isolation for VNF": "Guaranteed QoS",
                },
        },

        "resources": ["vgw"], #"vgw" is also interchangeably used as "vg"
        "applicableResources": "any",
        "identity": "cloud-atrributes",
        "policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vgw", "vgmux"],
        "policyType": "AllPolicy"
}

#
#Example 3:
#vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF with Burstable QoS
#
oof_cloud_selection_policy_instance3 = {
        "service": "cloudSelectionPolicy",
        "policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vDNS_VNF",
        "policyDescription": "Cloud Selection Policy for vDNS VNFs",
        "templateVersion": "0.0.1",
        "version": "oofMulti-cloudCasablanca",
        "priority": "3",
        "riskType": "test",
        "riskLevel": "2",
        "guard": "False",

        "content": {
                "vnfc": "vdns",
                "cloud-cost-evaluation": True,
                "cloud-deployment-intent": {
                        "Cloud Type (Cloud Provider)": {"VMware VIO", "Azure"},
                        "Infrastructure High Availability for VNF": True,
                        "Infrastructure Resource Isolation for VNF": "Burstable QoS",
                        "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": 25,
                },
        },

        "resources": ["vDNS"],
        "applicableResources": "any",
        "identity": "cloud-atrributes",
        "policyScope": ["vDNS", "US", "INTERNATIONAL", "vDNS"],
        "policyType": "AllPolicy"
}

#
# Example 4:
# vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF
# with Guaranteed QoS
#
oof_cloud_selection_policy_instance4 = {
        "service": "cloudSelectionPolicy",
        "policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vDNS_VNF",
        "policyDescription": "Cloud Selection Policy for vDNS VNFs",
        "templateVersion": "0.0.1",
        "version": "oofMulti-cloudCasablanca",
        "priority": "3",
        "riskType": "test",
        "riskLevel": "2",
        "guard": "False",

        "content": {
                "vnfc": "vdns",
                "cloud-cost-evaluation": True,
                "cloud-deployment-intent": {
                        "Infrastructure High Availability for VNF": True,
                        "Infrastructure Resource Isolation for VNF": "Guaranteed QoS",
                },
        },

        "resources": ["vDNS"],
        "applicableResources": "any",
        "identity": "cloud-atrributes",
        "policyScope": ["vDNS", "US", "INTERNATIONAL", "vDNS"],
        "policyType": "AllPolicy"
}

validate(oof_cloud_selection_policy_instance1, oof_cloud_selection_policy_schema)
validate(oof_cloud_selection_policy_instance2, oof_cloud_selection_policy_schema)
validate(oof_cloud_selection_policy_instance3, oof_cloud_selection_policy_schema)
validate(oof_cloud_selection_policy_instance4, oof_cloud_selection_policy_schema)

...

Parse OOF → MC Policy (Intent) API
If a Cloud owner does not support a specific "deployment-intent"
- Drop all the cloud regions for the cloud owner from the candidate list
For each cloud region // Public cloud could have different costs in different geographic locations
- Compute net_value based on cost
  - net_value = net_value + workload_deployment_cost
    - If Plugin of cloud owner supports cost based on "dollarCostEvaluationVM-Type" and/or "dollarCostEvaluationVM-FeatureGroup"
      - The workload deployment cost is computed per <instance type, cloud region> based on workload deployment cost policy described in Step 5b).
        Instance Type is derived from <Service, VNFC, cloud owner>
        More details are in 5b)
      - Implementation Notes:
        It is not mandatory for all plugins to implement this feature since the OOF → MC API has the flexibility of turning on this feature per <cloud owner, cloud region>
    - Else
      - The workload deployment cost is computed as a fixed cost per plugin
  Capacity Check
  - Private Clouds (OpenStack based)
    - Perform capacity check per specified Tenant (OpenStack Project)
      - The tenant is not currently passed in the OOF → MC API; this is figured out from simple mapping function; A simple mapping would be a tenant per <cloud owner, cloud region> as part of Multi-VIM plugin configuration.
    - If Capacity check fails, drop the cloud region out of the candidate list
  - Public Clouds or Other Clouds
    - Capacity check always succeeds //assumption: public cloud has infinite capacity

5b) Workload Deployment Cost Policy - Configured by the Operator

...

For R3, Workload Deployment Cost Policy can be stored in the form of configuration file(s) in the OOM K8S Persistent Volumes visible to the relevant MC plugin to simplify implementation. Beyond R3, this could be moved to the Policy DB. The details of the configuration are described below.

By default, each plugin supports a fixed cost for all workloads
- Optionally, plugin
Plugin
- of cloud owner can support cost based
on
- on "dollarCostEvaluationVM-Type" and/or "dollarCostEvaluationVM-FeatureGroup"
  - Where workload deployment cost includes dollar cost of VM Instance Type (based on <Service, VNFC, cloud owner>) and dollar cost (or discount) of other cloud-specific feature groups corresponding to the intent expressed under the deployment-intent keyword in the OOF → MC API
    - As an example, with respect to the deployment-intent, "Infrastructure Resource Isolation for VNF" with "Burstable QoS" can yield potential cost savings as compared to "Guaranteed QoS" by allowing smart over-subscription while still guaranteeing isolation
Note that the operator is free to choose the method of calculating the cost which includes initial cost, support cost & operational cost.
Note that the operator is free to choose what time duration the cost metric is specified for each of the MultiVIM plugins (e.g., cost per hour, cost per month) since they will do it consistently for each of the VIMs.

"Workload Deployment Cost Policy Example" depicted above has an exemplary description of this.

Step 5. MC → OOF – Return a net value for each <cloud owner, cloud

...

region>

6a) OOF Processing - cloud_net_value input in Multi-objective Optimization (need OOF code changes)

...

<cloud owner, cloud region> Candidate 3: $50, 190 kilometers => value: 290 <- pick this one

Step 6. OOF → SO - Return the target <cloud owner, cloud region> for the Service Instance + deployment-intent per vnfc

OOF ↔ SO API extension (VNFC deployment-intent) -- identical in content to SO <-> MC Policy API

Step 7. SO → MC - Deploy VNF template in the target <cloud owner, cloud region> for the Service Instance

...

Parse Template (e.g. OpenStack Heat Template)
- For each VNFC, instance type in the template
  - Fetch Cloud-Agnostic Workload Deployment Policy (Intent) based on <Service (e.g. vCPE), VNFC (e.g. vGW)>
    - Value/Content: <Policy JSON>
    - Note: The policy details are in Section 7b).
  - Parse Policy JSON
  - Modify template according to Intent
    - Intent examples of interest for R3
      - "Infrastructure High Availability (HA) for VNF"
      - "Infrastructure Resource Isolation for VNF"
        "Burstable QoS"
      - "Infrastructure Resource Isolation for VNF"
        "Guaranteed QoS"
Policy (Intent) Realization
- "Infrastructure High Availability (HA) for VNF"
  - OpenStack-based Cloud realization
    - For R3, Host-based anti-affinity using server groups //Beyond R3, Support other anti-affinity models at availability zone level etc.
    - Implementation Notes:
      - Instance "count" in heat template specifies VNFC scale out factor
      - While dynamic injection of server group into heat template is ideal, a simple starting point could be just switching to an alternate heat template which is identical to the deployment template and additionally has server group
  - Azure realization
    - Availability Set?
- "Infrastructure Resource Isolation for VNF" – { "qosProperty": { {"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"} } }
  - OpenStack-based VMware VIO Cloud realization
    - This can be achieved through min guarantee -- Max or limit (upper bound) & Min or Reservation (guarantee) are part of OpenStack flavor metadata
      - https://docs.openstack.org/horizon/latest/admin/manage-flavors.html
      - https://blogs.vmware.com/openstack/resources-guarantee-openstack-and-vmware-integrated-openstack/
- - - Example
      - VNFC with "Guaranteed QoS"
        "flavor-xyz-no-oversubscription"
        vCPU (Min/Max) - 16, Mem (Min/Max) - 32GB
      - Same VNFC with "Burstable QoS", 25% over-subscription
        "flavor-xyz-25-percent-oversubscription"
        vCPU (Min) - 16, Mem (Min) - 32GB
        vCPU (Max) - 20, Mem (Max) - 40GB
    - Only certain pre-defined over-subscription values are allowed to simplify implementation
    - Implementation Notes:
      - While dynamic injection of limit/reservation into flavor is ideal, a simple starting would be to be to switch to a pre-defined flavor in the environment file
        For aforementioned example
        Original flavor - "flavor-xyz-no-oversubscription"
        Modified flavor based on Policy - "flavor-xyz-25-percent-oversubscription"
- Implementation Notes:
  - From an implementation stand point, MC could would be exposing a Workload Deployment Policy (Intent) API
    - Input : deployment-intent, cloud owner, cloud region, deployment template, deployment environment file, ...
    - Output : Success or Failure with reason, modified deployment template, modified deployment environment file, ...

...

SO ↔ MC Policy API - Json Schema with use case examples as runnable python code - (the same isexact data is sent from OOF to SO. SO transparently echoes this data to MC)

...

Deployment-Intent
- 1. "Infrastructure Resource Isolation for VNF" – { "qosProperty": { {"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"} } }
  - Casablanca Plan
    - Only certain pre-defined over-subscription values are allowed to reflect practical deployment and simplify implementation
  - Dublin & Beyond Potential Plan
    - Creating instance types on demand for private clouds - to study
- 2. Cloud-agnostic Workload Deployment Policy (Intent)
  - Casablanca Plan
    - Cloud-Agnostic Workload Deployment Policy (Intent) can be directly mapped to specific realization (e.g. OpenStack Flavor, Azure Instance Type) to simplify implementation.
  - Dublin & Beyond Potential Plan
    - VIM Capability Discovery to populate Intent in A&AI (similar to HPA label discovery supported since R2)
      - VIM selection – Intent to be populated in A&AI for capability matching
      - VIM Deployment realization - Intent to specific realization mapping (e.g. OpenStack Flavor, Azure Instance Type) to be populated in A&AI
Policy-based capacity check & cloud-selection
- 3. Tenant Information is not passed in the OOF → MC API
  - Casablanca Plan
    - The tenant information is derived from a simple mapping function per <cloud owner, cloud region>
      - A simple mapping would be a tenant per <cloud owner, cloud region> as part of Multi-VIM plugin configuration.
      - Need to make sure that this scheme is synchronous with the SO → MC API path
  - Dublin & Beyond Potential Plan
    - Pass Tenant Information per <cloud owner, cloud region> in the OOF → MC API
- 4. Capacity Check for Public Clouds is not supported
  - Casablanca Plan
    - Public Clouds always pass the capacity check
  - Dublin & Beyond Potential Plan
    - Quota in Public Clouds - to study
  5. VM Instance type/VM Feature Group dollar-cost-based cloud selection
  - Casablanca Plan
    - VM Instance type/VM Feature Group dollar-cost-based cloud selection is not mandatory for all Multi-Cloud Plugins
    - If a Multi-Cloud Plugin does not support cost based on "dollarCostEvaluationVM-Type" and/or "dollarCostEvaluationVM-FeatureGroup"
      - The workload deployment cost is computed as a fixed cost per plugin
  - Dublin & Beyond Potential Plan
    - Deep dive further on dollar-cost-based cloud selection models/implementation for public/private clouds

...

Space shortcuts

Page tree

Versions Compared

Old Version 178

New Version 179

Key

Step 5. MC → OOF – Return a net value for each <cloud owner, cloud

region>

Step 6. OOF → SO - Return the target <cloud owner, cloud region> for the Service Instance + deployment-intent per vnfc

Step 7. SO → MC - Deploy VNF template in the target <cloud owner, cloud region> for the Service Instance