...
Gliffy Diagram size 1200 name Cloud Agnostic Intent Execution Workflow pagePin 3033
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
OOF Processing
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
{
"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"
} |
Private Cloud Setup (e.g. OpenStack)
- Pre-defined (including custom) flavors map to Instance types in Public Clouds
- Pre-defined flavors are created by the Cloud Admin before the Cloud is used by ONAP for workload deployment
VNFC to Instance Type Mapping
- One or more VNFCs (e.g. vCPE VGW) could map to an Instance Type
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 VM flavor, 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.
1. SO → OOF - Get Target <Cloud Owner, Cloud Region> for the Service Instances
2. OOF → Policy - Fetch Relevant Policies for the Service Instance (changes for this Feature)
2a. OOF Homing Enhanced Capacity Check & Cloud Selection Policy Example below - new in R3OOF → MC API
| Code Block | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
//flexibility of having cloud owner and region in the new API provides optional fine grained control, addresses capacity discrepancies across //different cloud owners/regions and ensures backward compatibility OOF -> MC { "VNFC{ "service": "vgwcloudSelectionPolicy", // "vgwpolicyName" 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 }, : "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": "OpenStackAll", // 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
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
"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 Resource Isolation 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"}
//{"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
}
}
|
SO Processing
- Same as R2
SO → MC API
- Same as R2
SO → MC Processing
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) Perform Cloud Agnostic Capability check for each <cloud owner, cloud region>
OOF → MC API
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
//flexibility of having cloud owner and region in the new API provides optional fine grained control, addresses capacity discrepancies 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"
},
} |
OOF->MC Processing
MC Inter-Cloud Placement (aka Homing) MC Workload Deployment Policy
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
"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 Resource Isolation 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"}
//{"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
}
}
|
Private Cloud Setup (e.g. OpenStack)
- Pre-defined (including custom) flavors map to Instance types in Public Clouds
- Pre-defined flavors are created by the Cloud Admin before the Cloud is used by ONAP for workload deployment
VNFC to Instance Type Mapping
- One or more VNFCs (e.g. vCPE VGW) could map to an instance type
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:
...
/admin/manage-flavors.html
}
}
|
SO Processing
- Same as R2
SO → MC API
- Same as R2
SO → MC Processing
MC Workload Deployment Policy
| Code Block | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
"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 Resource Isolation 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"}
//{"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 - Key Processing Steps
...