Page Comparison

Distributed Management Task Force - not ArchCom approved

• Scope for Franfurt
  • What is accepted by ArchCom is :  Current orchestration mechanism of OOM and DCAE can co-exist to support Central and Edge use cases

    • Non-DCAE Application Orchestration (A&AI, Policy etc.)

      • Applicable to Central/Edge Deployment

    • DCAE Application Orchestration  (DCAE MS – Collectors/Analytics/Event proc)

      • Applicable to Central/Edge Deployment
  • Focus on current gaps/new features from ONAP Edge standpoint and build them using consistent design across ONAP 
    • Implementation may vary for OOM and DCAE deployed component
  • Defer Controller Alignment discussions beyond Frankfurt
  Plan for Frankfurt & Beyond – Leverage Key Cloud Native Infra Orchestration Capabilities beyond K8S for ONAP management microservices
• (Required discussion here is acceptance of difference in edge or not, or whether this is for edge and central).
  
• Monitoring
  • Prometheus
• Logging
  • Fluentd 
•  Tracing
  • Jaeger 
Service MeshIstio/Envoy- "Extend Central K8S to register Edge Clouds"
• Centrally manage k8s Edge Clouds (k8s-clusters)
• Use Custom Resource Definition as Registry
• Provide ability to extend CRD to contain metadata

  • -Location label 

  • -Edge type (ICN, AWS, Azure, etc.) 

  • -External IP 

  • -Namespaces, user for authorization

• Edge Cloud Naming
  • Follow Cloud (AWS etc.) naming convention with additional operator name?

Questions: still to be answered:

• how to determine the location
• Is it OK to use different services for the applications centrally and distributed.  Which applications are taking these up. 

 Model Driven ONAP

<< req >>

 Orchestration of Contain Based VNFs

<<>>

 Applications on ONAP

<<?? >>

 API-GW

<<>>

 Runtime DB

<< >>

 ONAP CLI for VNF

<<??>>