Page History

Summary: Edge ScopingArchitecture & Work Items#ONAPEdgeMVP

...

Table of Contents

...

Distributed Edge Cloud Infrastructure Object Hierarchy (Stretch Goal - Beyond Casablanca)

Value:

Fine grained resource management & analytics for Distributed Edge Clouds

...

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

...

Multi-Cloud Policy Framework
- Assist OOF in target cloud region selection for VNF placement (aka homing) by summarizing cloud-specific capability, capacity & cost metrics (e.g. VMs could have different cost in different clouds, Infra High Availability (HA) for VMs in a VNF could have different cost in different clouds)through intent
  - Cloud Agnostic Intent (Policy) Execution Workflow - Steps 1- 64
- Dynamically modify the cloud specific VNF deployment template based on cloud-specific realization of the specified intent (e.g. Infra HA for VMs within a VNF could have different realizations across different clouds)
  - Cloud Agnostic Intent (Policy) Execution Workflow - Step 75
Intent Support
- Single realization option per Cloud Region for the specified Intent
Impact Projects:
- Multi-Cloud (Highest), OOF, SO (Minimal)
End-to-end use case demonstration:
- vCPE (no additional implementation dependency), vDNS

Phase 2 (Casablanca Stretch Goal) Summary (Build on Phase 1 Work):

Multi-Cloud Policy Framework
- Dynamically modify the cloud specific VNF deployment template based on cloud-specific realization of the specified intent – Impact to VNF configuration
  - E.g. High performance Intra-DC data plane networking with several realization choices
Intent Support
- Multiple realization options per Cloud Region for the specified Intent
Major Impact Projects:
- Multi-Cloud
Minor Impact Projects:
- SO, OOF, GNF Controller
Wiki Link:
- Edge Scoping - Casablanca Stretch Goal/Beyond Casablanca

References:

The sequence diagram below expands "Multi-Cloud/VNFM Deploy Apps" in Edge Scoping Sequence Diagram

Cloud Agnostic Intent (Policy) Workflow Summary (Phase 1 - Casablanca MVP):

Gliffy Diagram

size	1200
name	Cloud Agnostic Intent Execution Workflow
pagePin	40

Types of intent supported (through OOF Policy)
- "Infrastructure High Availability for VNF"
- "Infrastructure Resource Isolation for VNF": "Burstable QoS"
- "Infrastructure Resource Isolation for VNF": "Guaranteed QoS"
Related Specs/Jiras:
- OOF
  - OOF Policy spec -- https://wiki.onap.org/display/DW/OOF+Cloud+Agnostic+Policies; Policy Specification and Retrieval for OOF
- SO
  - SO Casablanca HPA design spec with cloud agnostic intent -- https://wiki.onap.org/display/DW/SO+Casablanca+HPA+Design
- Multi-Cloud
  - Generic API for SO to talk to different Multi cloud plugins to be updated with cloud agnostic intent -- https://gerrit.onap.org/r/#/c/60691/
  - HPA Cloud specific (flavor etc.) Mapping for R3 – HPA Policies and Mappings
  - Intent Cloud specific (flavor etc.) Mapping for R3 – Cloud Agnostic Intent and Mappings
- End-to-end use case
  - Support homing through OOF for vFW, vDNS –
    Jira
    server ONAP JIRA
    serverId 425b2b0a-557c-3c0c-b515-579789cceedb
    key SO-745
Useful Links:
- R2 HPA Integration testing – vCPE Use Case + OOF + HPA Tutorial: Design and Deploy based on ONAP#PrepareHEATtemplates

Phase 2 (Casablanca Stretch Goal) Summary (Build on Phase 1 Work):

Multi-Cloud Policy Framework
- Dynamically modify the cloud specific VNF deployment template based on cloud-specific realization of the specified intent – Impact to VNF configuration
  - E.g. High performance Intra-DC data plane networking with several realization choices
Intent Support
- Multiple realization options per Cloud Region for the specified Intent
Major Impact Projects:
- Multi-Cloud
Minor Impact Projects:
- SO, OOF, GNF Controller
Wiki Link:
- Edge Scoping - Casablanca Stretch Goal/Beyond Casablanca

References:

The sequence diagram below expands "Multi-Cloud/VNFM Deploy Apps" in Edge Architecture & Work Items Sequence Diagram

Cloud Agnostic Intent (Policy) Workflow Summary (Phase 1 - Casablanca MVP):

Gliffy Diagram

size	1200
name	Cloud Agnostic Intent Execution Workflow
pagePin	42

Cloud Agnostic Intent (Policy) Workflow Details (Phase 1 - Casablanca MVP):

Private Cloud Setup - OpenStack-based

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
VMware VIO Configuration for Min Guarantee feature

Cloud Agnostic Intent (Policy) Workflow Details (Phase 1 - Casablanca MVP):

Private Cloud Setup - OpenStack-based

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
VMware VIO Configuration for Min Guarantee feature
- Ref: https://docs.vmware.com/en/VMware-Integrated-OpenStack/5.0/com.vmware.openstack.admin.doc/GUID-D2C17D33-EC6C-4B8C-A9A3-25417917461F.html
- Ref: https://docs.openstack.org/horizon/latest/admin/manage-flavors.html
Create necessary tenants per <cloud owner, cloud region>
- Mapping of VNFC, VNF (VF module), Service (e.g. vCPE) to the corresponding tenant happens in the respective Multi-Cloud plugin.

VNFC to Instance Type Mapping

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
OpenStack-based Clouds
- Instance type maps to pre-defined Flavors

Microsoft AzurePre-defined Instance Types

Ref: https://docs.microsoftvmware.com/en-us/azure/virtual-machines/linux/sizes?toc=%2fazure%2fvirtual-machines%2flinux%2ftoc.json

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

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

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

Code Block

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

//
//Example 1: vCPE, Burstable QoS
//vCPE: Infrastructure Resource Isolation for VNF with Burstable QoS
//
{

"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": 
{
	//Note on cloudOwner, cloudRegion usage: e.g. 
		//"cloudOwner": "xyz", //can be a specific cloud owner such as Azure, VMware VIO, Wind River Titanium Cloud etc. 
		//"cloudRegion": "1", //can be a specific cloud region for a cloud owner
	//If no cloudOwner is specified, policy applies to all cloudOwners
	//If no cloudRegion is specified, policy applies to all cloudRegions
	
	{//new in R3
		"cost-intent": "TRUE",
	},			 			  	
  	
	{//new in R3
		"cloudOwner": "VMware VIO", //can be a specific cloud owner such as Azure, VMware VIO, Wind River Titanium Cloud etc.
		"deployment-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"}
			}
		}
	},
}

"resources": ["vgw", "vgmux"], //"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
//
{

"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": 
{
	//Note on cloudOwner, cloudRegion usage: e.g. 
		//"cloudOwner": "xyz", //can be a specific cloud owner such as Azure, VMware VIO, Wind River Titanium Cloud etc. 
		//"cloudRegion": "1", //can be a specific cloud region for a cloud owner

	//If no cloudOwner is specified, policy applies to all cloudOwners
	//If no cloudRegion is specified, policy applies to all cloudRegions
	
	{//new in R3
		"cost-intent": "TRUE",
	},		
			  	
	{//new in R3
		"deployment-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": 
			{		
				{"Guaranteed QoS": "TRUE"}
			}
		}
	}		  	
}

"resources": ["vgw", "vgmux"], //"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 VMs in a VNF & Infrastructure Resource Isolation for VNF with Burstable QoS
//
{

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

"content": 
{
	//Note on cloudOwner, cloudRegion usage: e.g. 
		//"cloudOwner": "xyz", //can be a specific cloud owner such as Azure, VMware VIO, Wind River Titanium Cloud etc. 
		//"cloudRegion": "1", //can be a specific cloud region for a cloud owner

	//If no cloudOwner is specified, policy applies to all cloudOwners

	//If no cloudRegion is specified, policy applies to all cloudRegions
	
	{//new in R3
		"cost-intent": "TRUE",
	},			
		  	
	{//new in R3
		"cloudOwner": "VMware VIO", //can be a specific cloud owner such as Azure, VMware VIO, Wind River Titanium Cloud etc.
		"deployment-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"}
			}
		}
	},
	
	{//new in R3
		"deployment-intent": 
		{
			"name": "Infrastructure High Availability (HA) for VNF", 
		}
	}, 	
}

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

}
//
//Example 4: 
//vDNS: Infrastructure HA for VMs in a VNF & Infrastructure Resource Isolation for VNF with Guaranteed QoS
//
{

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

"content": 
{
	//Note on cloudOwner, cloudRegion usage: e.g. 
		//"cloudOwner": "xyz", //can be a specific cloud owner such as Azure, VMware VIO, Wind River Titanium Cloud etc. 
		//"cloudRegion": "1", //can be a specific cloud region for a cloud owner

	//If no cloudOwner is specified, policy applies to all cloudOwners

	//If no cloudRegion is specified, policy applies to all cloudRegions

	{//new in R3
		"cost-intent": "TRUE",
	},			
			  	
	{//new in R3
		"deployment-intent": 
		{
			"name": "Infrastructure High Availability (HA) for VNF", 
		}
	}, 

	{//new in R3
		"deployment-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": 
			{		
				{"Guaranteed QoS": "TRUE"}
			}
		}
	}		  	
}

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

}

Step 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>. OOF will prune any <cloud owner, cloud region> which is not satisfying the standardized capabilities.

Step 4. OOF → MC - Push Cloud Agnostic Policy for the Service Instance

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) – need OOF code changes.

Code Block

language	py
theme	Emacs
title	OOF <-> MC API Examples (Step 4a)
linenumbers	true
collapse	true

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

JSON Schema with Use Case Examples: https://gerrit.onap.org/r/#/c/58531/2/usage-examples/oof-mc-r3-interface-examples.py

Code Block

language	py
theme	Emacs
title	Workload Deployment Cost Policy Example (Step 5b)
linenumbers	true
collapse	true

//
//Policy Relevant to Azure plugins
//
//fixed workload deployment cost for all workloads (simplifying assumption for R3)
{
	"workloadDeploymentCost": "100",
}



//
//Policy Relevant to Wind River OpenStack plugin
//
//fixed workload deployment cost for all workloads (simplifying assumption for R3)
{
	"workloadDeploymentCost": "100", (set to higher or lower value for testing)
}


...

5a) MC Processing (need MC code changes)

For each cloud owner

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

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

Plugin of cloud owner can support cost based 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> if the capacity check succeeds

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

Each service specifies an service-specific objective function that is stored as part of the service-specific policy and is used by OOF to evaluate the candidate <cloud owner, cloud region>. For simplicity of the example, let’s consider service that consists only of one VNF instance. The objective function has two components:

- distance from customer location to the VNF - the service designed assigns a weight for the distance: wd

- the cost of deploying the VNF in a location - the service designer assigns a weight for the cost: wc

OOF optimization function: min (wd*distance + wc*cloud_net_value)

If the service does not care about the cost at all, it would set wc = 0. If the service designer wants to minimize cost, he could set wd=0. Note that candidates that are too far can be eliminated by a distance constraint even before the optimization. For example, if the service has a distance constraint of at most 100 kilometers, then only those <cloud owner, cloud region> within 100 kilometers to the customer location would be considered in the objective function evaluation.

If the service designer wants to trade off between distance and cost, for example, they might set wd = 1, wc = 2. This would mean that one $1 increase in price is as valuable as 2 kilometers in distance.

<cloud owner, cloud region> Candidate 1: $100, 100 kilometers => value: 300

<cloud owner, cloud region> Candidate 2: $150, 80 kilometers => value: 380

<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

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

7a) MC Processing (need MC code changes)

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 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, ...

7b) Cloud-Agnostic Workload Deployment Policy (Intent)

For R3, 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.
- For R4 and beyond, this policy (optionally with specific realization options) will be passed from SO → MC. This is captured in the R4 and beyond workflow (Edge Scoping - Casablanca Stretch Goal/Beyond Casablanca).
This policy is exactly the same as the policies with "deployment-intent" in the Enhanced Capacity Check & Cloud Selection Policy for Homing described in Section 2.
An exemplary policy is depicted below.

Code Block

language	py
theme	Emacs
title	Cloud-Agnostic Workload Deployment Policy (Step 7b)
linenumbers	true
collapse	true

//Policy Example 1 - VNFC VGW which is part of vCPE service
{
	"Service": "vCPE"
	"VNFC": "vgw", //"vgw" is also intechangeably used as "vg"	
	
	{
		"cloudOwner": "VMware VIO", //can be a specific cloud owner such as Azure, VMware VIO, Wind River Titanium Cloud etc.
		"deployment-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"}

			}
		}
	}
}

//Policy Example 2 - VNFC vDNS which is part of vLoadBalancer/vDNS service
{
	"Service": "vDNS",
	"VNFC": "vDNS", 
	
	//By default, Policy (Intent) is applicable to all cloud owners/regions unless specified.
	{		
		"deployment-intent": 
		{
			"name": "Infrastructure High Availability (HA) for VNF", 
		}
	},
	
	{
		"deployment-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": 
			{		
				{"Guaranteed QoS": "TRUE"}
			}
		}
	}
}

Follow ups:

Use Cases for Integration testing
- vCPE
  - In the current state, this use case cannot support the intent "Infra HA for VMs in a VNF"
- vDNS
  - Can support intent "Infra HA for VMs in a VNF" and "Infrastructure Resource Isolation for VNF"
  - Nothing additional needed in OOF or MC
  - Changes needed in SO to call OOF API
    - Matti to follow up with Shankar
Policy DB – is there any restriction on the type of json objects that can be stored?
- Matti to follow up with Ankit

Implementation trade offs for Casablanca (R3) and potential Dublin (R4) plan:

- /VMware-Integrated-OpenStack/5.0/com.vmware.openstack.admin.doc/GUID-D2C17D33-EC6C-4B8C-A9A3-25417917461F.html
- Ref: https://docs.openstack.org/horizon/latest/admin/manage-flavors.html
Create necessary tenants per <cloud owner, cloud region>
- Mapping of VNFC, VNF (VF module), Service (e.g. vCPE) to the corresponding tenant happens in the respective Multi-Cloud plugin.

VNFC to Instance Type Mapping

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
- OpenStack-based Clouds
  - Instance type maps to pre-defined Flavors
- Microsoft Azure
  - Pre-defined Instance Types
    - Ref: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/sizes?toc=%2fazure%2fvirtual-machines%2flinux%2ftoc.json

Step 1. SO → OOF - Get Target <Cloud Owner, Cloud Region> for the Service Instances (no code changes for R3)

Step 2. OOF → Policy - Fetch Cloud Selection Policy for Homing

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

OOF Homing Enhanced Cloud Selection Policy based on Intent -- Schema with Use Case Examples as runnable python code:

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

                        # 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
                    					"Cloud Type (Cloud Provider)": {"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-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-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-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-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)

Step 3. OOF → A&AI - Fetch Cloud-Agnostic (Standardized) Capabilities for the Service Instance (no code changes for R3)

3a) OOF Processing - Perform Cloud Agnostic Capability check for each <cloud owner, cloud region>. OOF will prune any <cloud owner, cloud region> which is not satisfying the standardized capabilities.

Step 4. OOF → SO - Return the target <cloud owner, cloud region> for the Service Instance + deployment-intent per vnfc (code changes in OOF for R3)

OOF ↔ SO API extension - aligned to the OOF/SO API defined by SO Casablanca HPA Design to minimize the terminology set. The data between OOF to SO and SO to MC is identical -- details of the API are in section 5.

Step 5. SO → MC - Deploy VNF template in the target <cloud owner, cloud region> for the Service Instance (code changes in Multi-Cloud for R3)

5) MC Processing (need MC code changes)

Parse Template (e.g. OpenStack Heat Template)
- For each VNFC, instance type in the template
  - Parse Policy JSON coming in the SO ↔ MC directives API
  - Modify template (if needed) 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
- Determining the flavor (OpenStack-based VIMs) # same logic applies for instance type in Azure
  - Each VNFC uniquely maps to a Flavor - for e.g. VNFC "vgw" maps to "vgw-base", "vDNS" maps to "vDNS-base"
  - Beyond Casablanca
    - VNFC intent to realization mapping happens through A&AI.
- "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 "vgw" with "Guaranteed QoS"
        vCPU (Min/Max) - 16, Mem (Min/Max) - 32GB
        Maps to "vgw-Guaranteed-QoS" flavor for OpenStack-based VIMs
        Same VNFC with "Burstable QoS", 25% over-subscription
        vCPU (Min) - 16, Mem (Min) - 32GB
        vCPU (Max) - 20, Mem (Max) - 40GB
        Maps to "vgw-Burstable-QoS-25-percent-oversubscription" flavor for OpenStack-based VIMs
      - VNFC "vDNS" with "Guaranteed QoS" & "Infrastructure High Availability"
        Maps to "vDNS-Guaranteed-QoS" flavor and "vDNS-infrastructure-high-availability" heat template
    - 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 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 API extension - aligned to the SO/MC API defined by SO Casablanca HPA Design to minimize the terminology set

(This data is sent from OOF to SO. SO transparently echoes this data to MC)

Code Block

language	py
theme	Emacs
title	SO <-> MC Cloud-Agnostic Workload Deployment Policy API
linenumbers	true
collapse	true

#
#The same information is opaquely passed from OOF to SO
#

#
#Example 1: vCPE, Burstable QoS
#vCPE: Infrastructure Resource Isolation for VNF with Burstable QoS
#
   "oof_directives":{ 
      "directives":[ 
         { 
            "vnfc_directives":[ 
               { 
                  "vnfc_id":"vgw",
                  "directives":[ 
                     { 
                        "directive_name":"Resource-Isolation-Intent-directive",
                        "attributes":[ 
						   {
                              "attribute_name": "Infrastructure Resource Isolation for VNF",
                              "attribute_value": "Burstable QoS",
                           },
						   {
                              "attribute_name": "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage",
                              "attribute_value": "25",
                           },	    

                        ]
                     },
                  ]
               },
            ]
         },
       ]
     }


#
#Example 2:
#vCPE: Infrastructure Resource Isolation for VNF with Guaranteed QoS
#
   "oof_directives":{ 
      "directives":[ 
         { 
            "vnfc_directives":[ 
               { 
                  "vnfc_id":"vgw",
                  "directives":[ 
                     { 
                        "directive_name":"Resource-Isolation-Intent-directive",
                        "attributes":[ 
						   {
                              "attribute_name": "Infrastructure Resource Isolation for VNF",
                              "attribute_value": "Guaranteed QoS",
                           },
                        ]
                     },
                  ]
               },
            ]
         },
       ]
     }

#
#Example 3:
#vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF with Burstable QoS
#
   "oof_directives":{ 
      "directives":[ 
         { 
            "vnfc_directives":[ 
               { 
                  "vnfc_id":"vdns",
                  "directives":[ 
                     { 
                        "directive_name":"Resource-Isolation-Intent-directive",
                        "attributes":[ 
						   {
                              "attribute_name": "Infrastructure Resource Isolation for VNF",
                              "attribute_value": "Burstable QoS",
                           },
						   {
                              "attribute_name": "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage",
                              "attribute_value": "25",
                           },	    
                        ]
                     },
					 {
                        "directive_name":"Infrastructure-HA-Intent-directive",
                        "attributes":[ 
						   {
							  "attribute_name": "Infrastructure High Availability for VNF",                              
                           },
                        ]
					 },
                  ]
               },
            ]
         },
       ]
     }

#
# Example 4:
# vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF
# with Guaranteed QoS
#
   "oof_directives":{ 
      "directives":[ 
         { 
            "vnfc_directives":[ 
               { 
                  "vnfc_id":"vdns",
                  "directives":[ 
                     { 
                        "directive_name":"Resource-Isolation-Intent-directive",
                        "attributes":[ 
						   {
                              "attribute_name": "Infrastructure Resource Isolation for VNF",
                              "attribute_value": "Guaranteed QoS",
                           },
                        ]
                     },
					 {
                        "directive_name":"Infrastructure-HA-Intent-directive",
                        "attributes":[ 
						   {
							  "attribute_name": "Infrastructure High Availability for VNF",                              
                           },
                        ]

					 },
                  ]
               },
            ]
         },
       ]
     }

Follow ups:

Use Cases for Integration testing
- vCPE
  - In the current state, this use case cannot support the intent "Infra HA for VMs in a VNF"
  - This use case has been tested in R2 with OOF↔MC capacity check API
- vDNS
  - Can support intent "Infra HA for VMs in a VNF" and "Infrastructure Resource Isolation for VNF"
  - Nothing additional needed in OOF or MC
  - Changes needed in SO to call OOF API
    - Marcus from Intel is driving this
Policy DB – is there any restriction on the type of json objects that can be stored?
- Matti to follow up with Ankit

Implementation trade offs for Casablanca (R3) and potential Dublin (R4) plan:

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 aligning taking into account Cloud selection policy based on cost specific to Intent (leverage similarities to HPA label discovery supported since R2)
      - VIM selection – Intent to be populated in A&AI for capability matching
      - VIM Deployment realization - Intent(s) to specific realization mapping (e.g. OpenStack Flavor, Azure Instance Type) to be populated in A&AI
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) is not passed in the OOF → SO API & SO → MC API
  - Casablanca Plan
    - Cloud-Agnostic Workload Deployment Policy (Intent) can be stored in the form of Multi-Cloud configuration file(s) in OOM K8S Persistent Volumes to simplify implementation.
  - Dublin & Beyond Potential Plan
    - Pass this policy (optionally with specific realization options) from OOF → SO. SO passes the policy and associated information transparently from SO → MC. This is captured in the R4 and beyond workflow (Edge Scoping - Casablanca Stretch Goal/Beyond Casablanca).
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
- 6. The workload instance type model (Note 1 below) is not passed from OOF → MC. Rationale below.
  - Currently, the VNFC model supports only compute/memory/local storage. A comprehensive VNFC model needs to include HW generation (Intel Broadwell/Haswell, ARM etc.), HPA details (SR-IOV etc.) and more.
  - Casablanca Plan
    - Since the VNFC model standardization is in progress, VNFC mapping to VM Instance Type (OpenStack Flavor, Azure M4 etc.) happens in the Multi-Cloud plugin through configuration.
    - Note 1: An exception to the rule is a simple capacity check based on VM compute/memory/local storage which can be supported by the current instance type model.
  - Dublin & Beyond Potential Plan
    - Align with the modeling work and make progress

Cloud Resource Partitioning for Differentiated QoS (Combined with Previous)

...

Aggregated Infrastructure Telemetry Streams (Aligns with HPA requirements, Combining efforts with HPA)

Value

Edge Infrastructure Analytics complementing 5G VNF AnalyticsAnalytics complementing VNF Analytics
Increase the accuracy of placement decisions
Addresses gap in cloud provider solution – e.g. open source OpenStack does not have a comprehensive telemetry solution

Casablanca MVP

HPA metrics visualization
End-to-end use cases: vCPE, vDNS

Casablanca Stretch Goal

OOF to use aggregated telemetry information for fine-grained optimization

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	MULTICLOUD-254

...

ONAP, as in R2, collects the statistics/alarms/events from workloads (VMs) and take any close loop control actions such as Heal a process, scale-out, restart etc.. In R3 and beyond, infrastructure related statistics/alarms/events will be collected, generate actionable insights and take life cycle actions on the workloads. Infrastructure statistics normally include performance counters, NIC counters, IPMI information on per physical server node basis. To reduce the load on the ONAP, it is necessary that aggregated (summarized) information is sent to the ONAP from edge-clouds.

As part of this activity, intention is to create aggregation micro-service that collects the data from physical nodes (over collected and other mechanisms), aggregate the information (time based aggregation, threshold based aggregation, silencing etc.,..) based on the configurable rules and export the aggregate data to DCAE. This micro service can be instantiated by ONAP itself - one or more instances for edge-clouds at the ONAP-central itself using OOM, it could be instantiated at the edge-cloud using their own deployment tools or it could be deployed edge service providers at the regional site level. at the ONAP-central itself using OOM, it could be instantiated at the edge-cloud using their own deployment tools or it could be deployed edge service providers at the regional site level.

In R3, functionality is limited to HPA features and visualization. R3 stretch goal: It collects information from each compute node for all HPA features and keeps track of health and resource information. It would use this information in placement decisions by OOF for accurate results.

Even though the aggregation service is being developed in Multi-Cloud project, it is expected that this can be deployed at various places. The decision to deploy at various levels can be due to performance and regulatory reasons. Following deployments are envisaged at this time:

At the edge site level.
At the regional site level (on behalf of set of edge sites).
At the ONAP level (on behalf of set of edge sites)

Impacted projects (development activities)

...

View file

name	Promethus-aggregation.pdf
height	250

ONAP Edge Analytics with DCAE/DMaaP independent of closed loop (Stretch Goal - Beyond Casablanca)

Value

5G Analytics

ONAP Component	Life cycle phase	Enhancements
OOM - ONAP Central	Deploy	Separate ONAP-edge Instance per 'edge domain', (ie., separate from onap-central instance, of course) Note: Independent of any Edge CP's Orchestration components. SP uses a central-OOM with a 'policy' for deployment of an onap-edge instance, e.g., xyz edge provider with abc components, etc. However, onap-edge instance can be 'lighter weight' with subset of components needed (per MVP discussed below) Desirable to managed as a separate K8s cluster (ie., separate from onap-central instance, of course) and, only for onap-edge use, ie., don't use for other 'workloads' like network apps or 3rd party apps Central OOM to deploy the following ONAP edge instance DMaaP with mirror capability

Multi-Cloud Deployment in Edge Cloud (Stretch Goal - Beyond Casablanca)

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	MULTICLOUD-262

...

Space shortcuts

Page tree

Versions Compared

Old Version 167

New Version Current

Key

Distributed Edge Cloud Infrastructure Object Hierarchy (Stretch Goal - Beyond Casablanca)

Value:

Phase 2 (Casablanca Stretch Goal) Summary (Build on Phase 1 Work):

References:

Cloud Agnostic Intent (Policy) Workflow Summary (Phase 1 - Casablanca MVP):

Phase 2 (Casablanca Stretch Goal) Summary (Build on Phase 1 Work):

References:

Cloud Agnostic Intent (Policy) Workflow Summary (Phase 1 - Casablanca MVP):

Cloud Agnostic Intent (Policy) Workflow Details (Phase 1 - Casablanca MVP):

Private Cloud Setup - OpenStack-based

Cloud Agnostic Intent (Policy) Workflow Details (Phase 1 - Casablanca MVP):

Private Cloud Setup - OpenStack-based

VNFC to Instance Type Mapping

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

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

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

Step 4. OOF → MC - Push Cloud Agnostic Policy for the Service Instance

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

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

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

VNFC to Instance Type Mapping

Step 1. SO → OOF - Get Target <Cloud Owner, Cloud Region> for the Service Instances (no code changes for R3)

Step 2. OOF → Policy - Fetch Cloud Selection Policy for Homing

Step 3. OOF → A&AI - Fetch Cloud-Agnostic (Standardized) Capabilities for the Service Instance (no code changes for R3)

Step 4. OOF → SO - Return the target <cloud owner, cloud region> for the Service Instance + deployment-intent per vnfc (code changes in OOF for R3)

Step 5. SO → MC - Deploy VNF template in the target <cloud owner, cloud region> for the Service Instance (code changes in Multi-Cloud for R3)

Aggregated Infrastructure Telemetry Streams (Aligns with HPA requirements, Combining efforts with HPA)

Value

Casablanca MVP

Casablanca Stretch Goal

ONAP Edge Analytics with DCAE/DMaaP independent of closed loop (Stretch Goal - Beyond Casablanca)

Value

Multi-Cloud Deployment in Edge Cloud (Stretch Goal - Beyond Casablanca)