Page History

...

Gliffy Diagram

size	1200
name	Cloud Agnostic Intent Execution Workflow
pagePin	3437

Follow up :

Policy DB – is there any restriction on json objects store? - Matti to follow up with Ankit
Current R2 support – single VF module (VNFC) assumption per VNF for vCPE - follow up with Kang Xi to validate

...

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 (need code changes)

2a) OOF Processing - the fetched Policy is stored in a local data structure and is available for further use.2a. OOF Homing Enhanced Capacity Check & Cloud Selection Policy Example below - new in R3

Code Block

language	py
theme	Emacs
title	OOF Homing Enhanced Capacity Check & Cloud Selection Policy
linenumbers	true
collapse	true

{

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

}

3. OOF → A&AI - Fetch Cloud-Agnostic (Standardized) Capabilities for the Service Instance

3a) OOF Processing - Perform Cloud Agnostic Capability check for each <cloud owner, cloud region>

4. OOF → MC

...

- Push Cloud Agnostic Policy for the Service Instance - perform Cloud Specific Check (capability/capacity/cost metrics) for each registered Cloud Region in Multi-Cloud (need code changes)

4a) OOF Processing

The enhanced OOF ↔ MC capacity check API, described below, is filled based on the enhanced Capacity Check & Cloud Selection Policy for Homing retrieved in step 2).

Code Block

language	py
theme	Emacs
title	OOF <-> MC API Examples
linenumbers	true
collapse	true

//flexibility of

...

Code Block

language	py
theme	Emacs
title	OOF <-> MC API Examples
linenumbers	true
collapse	true

//flexibility of having cloud owner and region in the new API provides optional fine grained control, addresses capacity/cost discrepanciesdifferences across different //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"
	},
}

OOF->MC Processing

MC Inter-Cloud Placement (aka Homing) Policy

5a) MC Processing

For each cloud owner

Instance Type Handling
- 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"
Parse OOF → MC Policy API
For each cloud region // Public cloud could have different costs in different geographic locations
- net_value_cost = net_value_cost + cost_instance_type // cost per instance type is based on policy (for R3, it is picked up from Multi Cloud configuration file)
- net_value_cost = net_value_cost + cost_intent //e.g. "Infrastructure High Availability (HA) for VNF" may have additional cost
- 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

5. MC → OOF – Return a net value for each <cloud owner, cloud region> if the capacity check succeeds

6. OOF → SO - Return the target <cloud owner, cloud region> for the Service Instance

7. SO → MC - Deploy VNF template in the target <cloud owner, cloud region> for the Service Instance (need code changes)

OOF->MC Processing

MC Inter-Cloud Placement (aka Homing) Policy

Code Block

language	py
theme	Emacs
title	MC Inter-Cloud Placement (aka Homing) Policy
linenumbers	true
collapse	true

Code Block

language	py
theme	Emacs
title	MC Inter-Cloud Placement (aka Homing) Policy
linenumbers	true
collapse	true

		"intent": 
		{
			"name": "Infrastructure High Availability (HA) for VNF", 
				//realization thru OpenStack-based: anti-affinity, Azure: Fault Domain or
    			//Different anti-affinity models from ETSI -- host-level, rack-level, availability zone level
				//max-count in heat template - scale out factor
				//server-group in heat template - usable thru API and CLI in OpenStack, VMware VIO
		}
		"intent": 
		{
			"name": "Infrastructure High ResourceAvailability Isolation(HA) for VNF", 
				// realization possible without dedicating CPU and Memory, refer to section on "Cloud Resource Partitioning for Differentiated QoS" 
				// on how this can help in offering tiered services
			"qosProperty": 
			{
				{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}thru OpenStack-based: anti-affinity, Azure: Fault Domain or
    			//Different anti-affinity models from ETSI -- host-level, rack-level, availability zone level
				//max-count in heat template - scale out factor
				//{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}, {"operator", "OR"}, {"Guaranteed QoS": "TRUE"}server-group in heat template - usable thru API and CLI in OpenStack, VMware VIO
		}
		"intent": 
		{
			"name": "Infrastructure Resource Isolation for VNF", 
				// VMware VIO - tenant VDC CLI and API - configure the appropriate settings per tenantrealization possible without dedicating CPU and Memory, refer to section on "Cloud Resource Partitioning for Differentiated QoS" 
				// Burstableon QoShow isthis specifiedcan throughhelp minin guaranteeoffering (part of flavor metadata -- 
              	// https://docs.openstack.org/horizon/latest/admin/manage-flavors.html
			}
		}

SO Processing

Same as R2

SO → MC API

Same as R2

SO → MC Processing

MC Workload Deployment Policy

Code Block

language	py
theme	Emacs
title	MC Workload Deployment Policy
linenumbers	true
collapse	true

		"intent": 
		{
			"name": "Infrastructure High Availability (HA) for VNF", tiered services
			"qosProperty": 
			{
				{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}
				//{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}, {"operator", "OR"}, {"Guaranteed QoS": "TRUE"}
				// VMware VIO - tenant VDC CLI and API - configure the appropriate settings per tenant
				//realization Burstable QoS is specified through min guarantee (part of flavor metadata -- 
              	// https://docs.openstack.org/horizon/latest/admin/manage-flavors.html
			}
		}

SO Processing

Same as R2

SO → MC API

Same as R2

SO → MC Processing

MC Workload Deployment Policy

Code Block

language	py
theme	Emacs
title	MC Workload Deployment Policy
linenumbers	true
collapse	true

		"intent": 
		{
			"name": "Infrastructure High Availability (HA)thru OpenStack-based: anti-affinity, Azure: Fault Domain or
    			//Different anti-affinity models from ETSI -- host-level, rack-level, availability zone level
				//max-count in heat template - scale out factor
				//server-group in heat template - usable thru API and CLI in OpenStack, VMware VIO
		}
		"intent": 
		{
			"name": "Infrastructure Resource Isolation for VNF", 
				// realization possible without dedicating CPU and Memory, refer to section on "Cloud Resource Partitioning for Differentiated QoS" thru OpenStack-based: anti-affinity, Azure: Fault Domain or
    			//Different anti-affinity models from ETSI -- host-level, rack-level, availability zone level
				//max-count onin howheat thistemplate can- helpscale in offering tiered services
			"qosProperty": 
			{
				{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}out factor
				//server-group in heat template - usable thru API and CLI in OpenStack, VMware VIO
		}
		"intent": 
		{
			"name": "Infrastructure Resource Isolation for VNF", 
				//{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}, {"operator", "OR"}, {"Guaranteed QoS": "TRUE"} realization possible without dedicating CPU and Memory, refer to section on "Cloud Resource Partitioning for Differentiated QoS" 
				// VMwareon VIOhow -this tenantcan VDChelp CLIin andoffering API - configure the appropriate settings per tenanttiered services
			"qosProperty": 
				// {
				{"Burstable QoS is specified through min guarantee (part of flavor metadata -- 
              	// https://docs.openstack.org/horizon/latest/admin/manage-flavors.html
			}
		}

OOF → Multi-VIM/Cloud Policy API - Key Processing Steps

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"

...

net_value_cost = net_value_cost + cost_instance_type // cost per instance type is based on policy (for R3, it is picked up from Multi Cloud configuration file)
net_value_cost = net_value_cost + cost_intent //e.g. "Infrastructure High Availability (HA) for VNF" may have additional cost
Capacity Check – Continue R2 Plan
- Private Clouds (OpenStack based)
  - Capacity check per Tenant (OpenStack Project)
    - returns yes or no
- Public Clouds or Other Clouds
  - Capacity check per tenant
    - return yes always //assumption: public cloud has infinite capacity
If infra capacity is finite (Private cloud or Public cloud with reserved instances) // e.g. object of interest is OpenStack Project with a quota (upper limit) for cpu, mem and local disk
- Option A: (potentially supportable with OpenStack based clouds, other clouds to be investigated)
  - normalized_cpu_per_object = (current_cpu_used_object + instance_type_cpu*number_of_instances_of vnfc)/total_cpu_object
    - if normalized_cpu_per_object > 1, capacity check failed
  - normalized_mem_per_object = (current_mem_used_object + instance_type_mem*number_of_instances_of_vnfc)/total_mem_object
    - if normalized_mem_per_object > 1, capacity check failed
  - normalized_disk_per_object = (current_disk_used_object + instance_type_disk*number_of_instances_of_vnfc)/total_disk_object
    - if normalized_disk_per_object > 1, capacity check failed
  - net_value_capacity = normalized_infra_capacity = wcpu*normalized_cpu_per_object + wmem*normalized_mem_object + wdisk*normalized_disk_per_object // wcpu, wmem, wdisk are specified in a multi-cloud configuration file; wcpu + wmem + wdisk = 1
- Option B: (under study)
  - normalized_instances_per_object = (current_used_reserved_instances + number_of_instances_of_vnfc)/total_reserved_instances
  - net_value_capacity = normalized_instances_per_object

...

": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}
				//{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}, {"operator", "OR"}, {"Guaranteed QoS": "TRUE"}
				// VMware VIO - tenant VDC CLI and API - configure the appropriate settings per tenant
				// Burstable QoS is specified through min guarantee (part of flavor metadata -- 
              	// https://docs.openstack.org/horizon/latest/admin/manage-flavors.html
			}
		}

OOF → Multi-VIM/Cloud Policy API - Other

...

Space shortcuts

Page tree

Versions Compared

Old Version 126

New Version 127

Key

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 (need code changes)

4. OOF → MC

- Push Cloud Agnostic Policy for the Service Instance - perform Cloud Specific Check (capability/capacity/cost metrics) for each registered Cloud Region in Multi-Cloud (need code changes)

OOF->MC Processing

5. MC → OOF – Return a net value for each <cloud owner, cloud region> if the capacity check succeeds

6. OOF → SO - Return the target <cloud owner, cloud region> for the Service Instance

7. SO → MC - Deploy VNF template in the target <cloud owner, cloud region> for the Service Instance (need code changes)

OOF->MC Processing

SO Processing

SO → MC API

SO → MC Processing

SO Processing

SO → MC API

SO → MC Processing