Team:

Lead: 

ramki krishnan

Team:

ramki krishnan , Srinivasa Addepalli, Vimal Begwani, Mike Elliott, Vijay Venkatesh Kumar , Avi Chapnick , Borislav Glozman , Fernando Oliveira , Tal Liron , Margaret Chiosi , ravi rao , Raghu Ranganathan , Michael O'Brien , Xin Miao , Simone Mangiante , Timo Perala,  Davide Cherubini, John Ng

Others – please add yourself if you are interested

Meetings:

Every week as part of Edge Automation WG – Edge Automation through ONAP

References:

1. ONAP Dublin Architecture Requirements: https://wiki.lfnetworking.org/display/LN/OPNFV-ONAP+January+2019+Session+Proposals?preview=/8257582/10551784/2019-01%20Dublin%20Architecture%20Requirements-pa1.pptx
2. DCAE Platform Requirements: https://wiki.onap.org/download/attachments/28379482/DCAE%20Platform%20Requirements.pptx?api=v2

Activity Description:

Starting with Analytics, describe the options and recommendations for distributing management (ONAP etc.) functions.

Problem Statement:

• Management Workloads
  • Currently, Multiple Orchestrators for Management Workloads. 
    • ONAP Central Management   – OOM
    • Analytics Central/Distributed Management   – DCAE (ONAP, SP internal, Third Party)
  • There is an opportunity to get some alignment across multiple orchestrators which will be greatly beneficial especially in Distributed Edge environment
• Managed Workloads (SDC, SO, OOF etc)
  • Fully Support for containerized network functions (work in progress)
  • Support for non-network functions (VM and Container based), e.g. vProbe, Automation Apps

Solution Direction:

• Leverage existing capabilities, and select what; or motivate new approaches
• Management Workload:
  • Align on a single orchestrator solution for all management workloads
• Managed Workload:
  • Enhance SDC, SO, A&AI, MC etc. to support containerized functions
  • Leverage ONAP for deploying and managing non-network functions
• Longer-term: 
  • Explore feasibility for orchestration alignment between managed workload and management workload
• Cloud-Native-foundation: 
  • Leverage K8S (Operators, Custom Resource Definitions etc.) for Distributed Systems Management
    • Image management – at scale rolling upgrade

    • Policy/Configuration change – notify only deltas

  • Leverage Istio Service Mesh (Distributed Tracing etc.) for Component Performance Management 

Architectural Deployment Scenarios to consider:

Management Workloads

Managed Workloads

• Managed workload instantiation is always started by ONAP Central components 
  
  • If "Edge using certain ONAP management workload functions as an Offload" as described in the previous table, the corresponding workload LCM functions will be taken care of by offloaded ONAP management components 
    

No change is envisioned in the workload instantiation from a ONAP user perspective. 

Distributed Management application Requirements / Considerations 

Definitions

Day0 configuration:  Configuration that is applied at the time of VNF instantiations (Example: Ether config-drive, config-init or config-map)

Day 2 configuration: on-going configuration after Day-0 configurations

(in VNFs, Day 1 configuration is treated as Day 2 configuration in the following table)

Management application:  Can be ONAP component or equivalent component from third parties

Solution Options

Quick Analysis of All Options 

• Option 1 (uses same infrastructure that is available for deploying VNFs)

  • Option 1 Pros (with respect to other options)
    • Since it uses same infrastructure as VNFs, any enhancements done in orchestration for VNFs comes free for ONAP management applications .
    • ONAP Management applications requiring selective placement (based on criteria such as hardware capabilities, latency, distance, affinity and anti-affinity) can be satisfied using OOF.
    • ONAP management applications that have 1:1 correspondence with VNFs can be brought together.
    • ONAP management applications of different form factors (such as VM and containers) can be taken care.
    • ONAP management applications can be placed in cloud regions with different technologies
    • Single orchestrator for both managed and management applications.
  • Option 1 Cons:
    • Majority of ONAP management applications today are described using helm and hence they can be deployed easily using option 1.  But, there are many ONAP management applications are described using TOSCA. They can't be deployed using option 1 until TOSCA support is added in SO.  Since Cloudify-TOSCA plan is not in the roadmap for Dublin., It is also an understanding that Cloudify-TOSCA support in SO may not happen this year. 
    • Some of the ONAP components are not instantiated using OOM. They get instantiated dynamically by CLAMP framework.  Supporting CLAMP initiated ONAP management application deployment with SO may require significant development.
  • Option 1 Analysis:
    • Any management application that is described in HEAT/Helm, that is independent of CLAMP can leverage this option. 
    • Since there are applications that are described in Cloudify-TOSCA, it is felt that this option alone can't satisfy the critical requirement 
• Conclusion:
  • It was considered pragmatic to not consider option 1 further and synergize Options 2 and 3 to produce a best of breed solution.

Requirements and Narrowed-down Solution Options Mapping

Assumptions

Architectural Options:

Discussion Kick off:

Various Architectural Options: https://wiki.onap.org/download/attachments/28379482/ONAP-DDF-Distributed-Analytics-framework-v1.pptx?api=v2

Definition of done:

• This activity is closed when there is a:
  • Description of alternative concepts for distributing the ONAP functionality.
  • A recommendation for which alternatives to pursue (and when). 

Expected Timeframe:

 This activity is expected to conclude at/before the start of April, 2019 by the ONAP Architecture meeting at ONS. 

Definitions: 

Conclusion: 

Other Deliverables:

LF blog and Architecture white paper during ONS time frame.