You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Purpose:

Main purpose of F-GPS (a.k.a. Valet) is, with considering placement rules,  (1) to precisely check capacity & capability of target DC or edge site and then, (2) to determine VNF placements.

  • Placement rules include Affinity and Anti-affinity.
  • Scopes of placement rules are, in a target DC or edge site, across availability-zones and optionally, across compute hosts.
  • Applications of placement rules are workloads within a VNF or workloads across VNFs.
  • Opportunity to standardize many other placement rules (e.g., Exclusivity, Quorum-Diversity) in VNFD and Policy.

Owner :  TBD

Participating Companies: Intel, VMware, AT&T

Operator Support: TBD

Parent page: TBD


Use Case Name

Showcase VNFTest EnvironmentIntegration Team Liaison
5G VNF teaming (TBD)TBD

TBD

5G VNFs teaming use case: A VNF instance has 2 workloads (2 VM instances) that must be placed in a same zone (or compute host) because of the high throughput requirement between workloads. Meanwhile, 2 more replicas of the VNF instance must be placed in different zones (or different compute hosts) of the same DC because of the high-reliability requirements for the VNF.

To meet these requirements, each VNF instance must specify an Affinity rule for its 2 workloads. Meanwhile, the same type of workloads in those 3 VNF instances must specify an Anti-affinity rule.


Dublin Focus:

  • Seed code for placement decisions in OpenStack cloud and evaluate in an OpenStack testbed for this version. 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 DC 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).
  • Placement decisions for Affinity and Anti-Affinity among zones of target DC. 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 placement request (Stretch Goal). Until this is ready, evaluate with a manual/hard-coded specification.

Impacted Projects 

ProjectPTLJIRA Epic / User Story*Requirements
OOF/HAS

  1. A repository to keep the ML/DL Model Management service
  2. A repository to keep the application image dispatcher service
OOMMike Elliott
  1. Helm Charts for PNDA based analytics framework packages
  2. Helm Charts for various analytics applications
  3. Helm Chart for Cloud infra Event/Alert/Alarm/Fault Normalization & Dispatching microservice
Multi-VIM/Cloud


  1. Add new config-service plugin to work with Edge side Consul for configuration
Multi-VIM/CloudBin Yang

Cloud infra Event/Alert/Alarm/Fault Normalization & Dispatching microservice development

  1. Integrate DMaaP (Kafka) client for communication to ONAP Central 
  2. Receive Event/Alert/Alarm/Fault from infra analytics application
  3. Normalize from cloud specific Event/Alert/Alarm/Fault format to cloud agnostic (ONAP internal) Event/Alert/Alarm/Fault format
  4. Dispatch Event/Alert/Alarm/Fault to ONAP central using DMaaP (Kafka) client






  • No labels