Page History

...

//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.
		"cloudRegion": "All", //can be a specific cloud region for a cloud owner
		"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.
	{		
		"cloudOwnerdeployment-intent": "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
		"deployment-intent": 
		{
			"name": "Infrastructure High Availability (HA) for VNF", 
		}
	},
	
	{
		"deployment-intent": 
		{
			"name": "Infrastructure High Availability (HA) for VNF", 
		}
	},
	
	{
		"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
		"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"}
			}
		}
	}
}

...

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

...

• 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 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 SO → MC. This is captured in the R4 and beyond workflow (Edge Scoping - 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<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
    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
      • Deep dive further on dollar-cost-based cloud selection models/implementation for public/private clouds

  • 65.  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 modelling modeling work and make progress

Cloud Resource Partitioning for Differentiated QoS (Combined with Previous)

...