Page History

...

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

Cloud Agnostic Intent (Policy)

...

Workflow Summary:

...

//
//InPolicy relevant to 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"
	}, 
}

...

• Parse OOF → MC Policy API 
• 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 
      • 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)
      • 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>
  • 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

...

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 to simplify implementation.  Beyond R3, this could be moved to the Policy DB. The details of the configuration are described below.

...

• 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> 
    • Parse Policy JSON
    • Modify template according to Intent - intent examples below
      • "Infrastructure High Availability (HA) for VNF" 
      • "Infrastructure Resource Isolation for VNF"   
        • "Burstable 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 on implementation: 
        • 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 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 on implementation:
        • 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" 

...