Page History

...

Follow ups:

• Policy DB – is there any restriction on json objects store? 
  • Matti to follow up with Ankit
• Intent – "Infrastructure Resource Isolation for VNF" – { "qosProperty": { {"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"} } }
  
  • Only certain pre-defined over-subscription values are allowed to simplify implementation 

...

• One or more VNFCs (e.g. vCPE VGW) could map to an Instance Type
  • Use Case: Residential Broadband vCPE (Approved)
    • Ref: https://github.com/onap/demo/blob/a19bd423c1e4d2f5552bab090ba2650c38fa7192/heat/vCPE/vgw/base_vcpe_vgw.yaml
    • Ref: https://github.com/onap/demo/blob/ab98f6a0db3df8f5232395d899e96462dbc11159/heat/vCPE/vgw/base_vcpe_vgw.env

Operator Configuration – Multi-VIM/Cloud Plugin

The operator/service provider who uses ONAP will choose which VIMs to use and include the appropriate MultiVIM plugins in his ONAP deployment. For example, let’s assume they pick private Openstack, private VMWare, and public Azure as the platform to run their services on.

For each MultiVIM plugin, operator configures the following information:

• For each Instance Type, the cost of that VM to the operator. Note that this costs includes the (potentially discounted) list price for the VM, support cost, and operations cost. The last one is definitely operator specific.
• Operator also specify the cost for each feature: HA, etc
• 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. 

Workflow Details

1. SO → OOF - Get Target <Cloud Owner, Cloud Region> for the Service Instances

2. OOF → Policy - Fetch Enhanced Capacity Check & Cloud Selection Policy for Homing 

2a) OOF Processing - the fetched Policy is stored in a local data structure and is available for further use (need OOF code changes).

Cloud Agnostic Intent (Policy) Workflow Details:

1. SO → OOF - Get Target <Cloud Owner, Cloud Region> for the Service Instances

2. OOF → Policy - Fetch Enhanced Capacity Check & Cloud Selection Policy for Homing 

2a) OOF Processing - the fetched Policy is stored in a local data structure and is available for further use (need OOF code changes).

{

"service": "cloudSelectionPolicy",
"policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vCPE_VNF",
"description": "Cloud Selection Policy for vCPE VNFs",
"templateVersion": "0.0.1",
"version": "oofMulti-cloudCasablanca",
"priority": "3",
"riskType": "test",
"riskLevel": "2",
"guard": "False",

"content": 
{
	{
		"cloudOwner": "All", //can be a specific cloud owner such as Azure, VMware VIO, Wind River Titanium Cloud etc.
		"cloudRegion": "All", //can be a specific cloud region for a cloud owner
		"capacityCheck": "TRUE", //perform capacity check per <cloud owner, cloud region>
		"dollarCostEvaluationVM-Type": "TRUE", //evaluate dollar cost per VM type if operator has configured a policy
		"dollarCostEvaluationVM-FeatureGroup": "TRUE" //evaluate dollar per feature/group of features if operator has configured a policy
	},		 			  	
}

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

}

...

//flexibility of having cloud owner and region in the new API provides fine grained control, addresses capacity/cost differences across different //cloud owners/regions and ensures backward compatibility

OOF -> MC
{
	"VNFC": "vgw", //"vgw" is also intechangeably used as "vg" //new in R3

	{   //new in R3
		"cloudOwner": "All", //can be a specific cloud owner such as Azure, VMware VIO, Wind River Titanium Cloud etc. 
		"cloudRegion": "All", //can be a specific cloud region for a cloud owner
		"dollarCostEvaluationVM-Type": "TRUE", //evaluate dollar cost per VM type if operator has configured a policy
		"dollarCostEvaluationVM-FeatureGroup": "TRUE" //evaluate dollar per feature/group of features if operator has configured a policy
	},			 			  	
  		
	{
		"cloudOwner": "OpenStack", 	// new in R3, 
								   	// different cloud owners may need different capacities for the same VNFC because of implementation differences
		"cloudRegion": "All", 		// new in R3, 
							 		// different cloud regions for a cloud owner may need different capacities for the same VNFC due to different SW
							 		// versions and HW configuration	

		"capacityProperty": //same as R2, presence of this means capacity check needs to be done for the <cloud owner, cloud region>
		{ 		 		
			"request": 
				"{\"vCPU\": {\"quantity\": {\"get_param\": \"REQUIRED_VCPU\"}, \"Memory\": {\"quantity\": {\"get_param\": \"REQUIRED_MEM\"}, 	
				\"unit\": 	\"GB\"}, \"Storage\": {\"quantity\": {\"get_param\": \"REQUIRED_DISK\"}, \"unit\": \"GB\"}}"
		}		
	},
}

//return netValue per <cloud owner, cloud region>
//cloud regions which fail capacity check are not in this list
MC -> OOF
{
	{
		"cloudOwner": "OpenStack",
		"cloudRegion": "1",
		"netValue": "99"
	},
	{
		"cloudOwner": "VIO",
		"cloudRegion": "5",
		"netValue": "100"
	},
	{
		"cloudOwner": "Azure",
		"cloudRegion": "3",
		"netValue": "101"
	},
}

5a) MC Processing (need MC code changes)

For each cloud owner

...

• Instance Type is passed in the capacity check API from OOF (Discuss) //Note, SO → MC passes OpenStack flavor name in the Heat Template/Env file
• Convert to appropriate instance type based on intent //e.g. "Infrastructure Resource Isolation for VNF" may result in a different instance type if the cloud owner supports "Burstable QoS"

...

		"cloudOwner": "Azure",
		"cloudRegion": "3",
		"netValue": "101"
	},
}

//
//In MC Azure Plugin
//


//<Service, VNFC> to instanceType Mapping
{
	{
		"Service": "vCPE"
		"VNFC": "vgw", //"vgw" is also intechangeably used as "vg"	
		"cloudOwner": "Azure",
		"instanceType": "x1"
	}
}


//workload deployment cost for instance type per cloud region 
{
	{
		"cloudRegion": "5",
		"instanceType": "x1",
		"workloadDeploymentCost": "100"
	}, 
	{
		"cloudRegion": "10",
		"instanceType": "x1",
		"workloadDeploymentCost": "120"
	}, 
}

5a) MC Processing (need MC code changes)

For each cloud owner

• Parse OOF → MC Policy API 
• For each cloud region // Public cloud could have different costs in different geographic locations
  • net_value = net_value + workload_deployment_cost 
    • The workload deployment cost is computed per <instance type, cloud region>
      • Instance Type is derived from <Service, VNFC, cloud owner>
    • More details are in 5b)
  • Capacity Check 
    
    • Private Clouds (OpenStack based)
      • Perform capacity check per specified Tenant (OpenStack Project)
      • 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 Configuration - Configured by the Operator

The operator/service provider who uses ONAP will choose which VIMs to use and include the appropriate MC plugins in his ONAP deployment. For example, let’s assume they pick private Openstack, private VMWare, and public Azure as the platform to run their services on.

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

• Workload deployment cost includes dollar cost of Instance Type (based on <Service, VNFC, cloud owner>) and dollar cost (or discount) of other cloud-specific features corresponding to "Cloud-Agnostic Workload Deployment Policy (Intent)" described in workflow Step 7.
  • As an example, with respect to the Intent "Infrastructure Resource Isolation for VNF", "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.

...

• Perform capacity check per specified Tenant (OpenStack Project)
• If Capacity check fails, drop the cloud region out of the candidate list

...

5. MC →  OOF – Return a net value

...

for each <cloud owner, cloud region> if the capacity check succeeds

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

...

7b) Policy (Intent) Database

• For R3, store Cloud-Agnostic Workload Deployment Policy (Intent) can be stored in the form of configuration file(s) in the OOM K8S Persistent Volumes to simplify implementation.

...