Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Main purpose of F-GPS (a.k.a. ONAP-Valet) is, with considering new placement rulespolicies,  (1) to precisely check capacity & capability of target Cloud Region and then, (2) to determine VNF placements (i.e., target zone or compute host for each workload of VNF).

  • Placement rules New placement policies include Affinity and Anti-affinity.
  • Scopes of placement rules Affinity/Anti-affinity are, in a target Cloud Region, across availability-zones and optionally, across compute hosts.
  • Applications of placement rules are Affinity/Anti-affinity are workloads within a VNF or workloads across VNFs.
  • Opportunity to standardize many other placement rules policies (e.g., ExclusivityBeside Affinity/Anti-affinity, include Exclusivity, Quorum-Diversity) in VNFD and Policy.
  • Integrated into OOF/HAS (maybe initially as dark mode for evaluation in Dublin).

...

Showcase VNFTest EnvironmentIntegration Team Liaison
Core VNFs in 5GTBD

OOF

5G Data Plane Performance use case:

...

Place 5G VNF in a specific DC location/zone in a distributed cloud for user(s) proximity. A single cloud control plane (Cloud Region) is managing several distributed DC locations/zones. 

Dublin Focus:

  • Seed code for placement decisions for OpenStack cloud and evaluate in an OpenStack testbed. Later, extend to the other clouds including Azure and AWS.
  • Capacity & Capability checking for an OpenStack cloud: 1)  
    • Checking the number of zones of the target Cloud Region to solve the Anti-affinity rules
    , 2)
    • .
    • Checking available capacity of each zone to solve Affinity rule
    , 3)
    • .
    • Checking available host profiles of each zone to solve flavor matching (i.e., Host-Aggregates) (Stretch Goal).
  • Placement decisions for Affinity and Anti-Affinity among zones of target Cloud Region. Optionally, decisions go into compute hosts (for private cloud case).
  • Defining Affinity and Anti-affinity rules in Policy (Stretch Goal). Until this is ready, evaluate with a manual/hard-coded policy.
  • Specifying Affinity and Anti-affinity rules in homing/placement request (Stretch Goal). Until this is ready, evaluate with a manual/hard-coded specification.
  • Distributed cloud modelling immediately relevant to F-GPS - a single cloud control plane (Cloud Region) to be able manage several distributed DC locations/zones. 
  • Leverage capacity alerts (significant change in capacity) from Model-driven Distributed Analytics work.

...

ProjectPTLJIRA Epic / User Story*Requirements
OOFSarat Puthenpura
  • OSDF: support new homing/placement constraints (Affinity, Anti-affinity, and resources per workload (e.g., VM) of VNF) as policies and /or VNFD model.
  • HAS: 1) implement new placement constraints and interact with F-GPS, 2) deal with new placement decisions returned from F-GPS.
Multi-VIM/Cloud


  • Collect Availability-Zone capacity data from Clouds.
  • Open new API to communicate with F-GPS for per Availability-Zone capacity checking.
  • Enable the placement decisions (e.g., update Heat env in OpenStack case) to send them to Cloud orchestrator (e.g., OpenStack) via plugins.
A&AI
  • Open (new) API for F-GPS to obtain Availability-Zone information of each Cloud Region.
  • Distributed cloud modelling immediately relevant to F-GPS - a single cloud control plane to be able manage several distributed DC locations/zones. 

...

  • Need end-to-end workflows: The overall flow is ready (below), and detailed will be ready soon.
  • Modeling
    • Affinity/Anti-affinity: Investigated ETSI NFV-IFA and turns out that it VNFD includes Affinity/Anti-affinity specification per DC (NFVI-PoP), Zone (Availability-zone), and compute server (NFVI-node). 
    • Distributed cloud: Each Cloud Region has multiple Availability-zones (DCs)
  • Capacity check: Fine grained, per Availability-zone (or DC).

...