Title: Robust ONAP Platform Controller for LCM in a Distributed Edge Environment (In Progress) Source: ONAP Architecture Task Force on Edge Automation - Lead: VMware - Core Team: Amdocs, AT&T, Intel, VMware Others: Fujitsu, Huawei, Nokia, Red Hat, Vodafone, Verizon - Date: March 2019 - Link: https://wiki.onap.org/display/DW/Edge+Automation+through+ONAP+-+Distributed+Management+%28ONAP+etc.%29+components

ONAP Orchestrator Feature (High level view) Dublin All ONAP projects are deployed/bootstrapped through helm under OOM DCAE Service components are deployed using Cloudify/blueprint ONAP deployment is single site HA not enforced as single orchestration function Infrastructure(k8s) is assumed to installed on compute/VM nodes Dynamic instantiation of application limited to DCAE Future Needs Need for multi-site, multi-tenant infrastructure management, deployment and Life-Cycle Management of components either near or co-located at cloud-regions (e.g customer edges, network edges, RICs, core network centers etc..) requiring scale-out across locations. Provide Flexible Policy Driven Configuration and Deployment Management Support for Manager of Manager model to distribute and scale necessary central functions Support for containerized and VM based workload deployment Consistent onboarding and modelling for all management components Single dashboard / system to onboard cloud-regions Real-time Dashboard and inventory of all management apps & components that are deployed and active. Support Geo-Redundant Deployment and Failure Recovery Support for third party management components

ONAP Management Application Deployment Requirements (From EA-WG wiki)

ONAP Management Application Deployment Requirements – Continued Miscellaneous - Infrastructure LCM; bring up necessary K8S clusters only if needed

ONAP Orchestration – Current functional Gaps (Dublin) Design No standardized configuration modelling enforced in Helm templates On-demand Service design creation and deployment of single/composed management application Instantiation Control Loop flow deployment and support through CLAMP/Policy/SDC xNF Event based application management (deployment and configuration) Run-time Dynamic configuration management through central ONAP Policy No backward support on Tosca based ONAP application and workflow Dynamic DMAAP topics provisioning/configuration for management application Consolidated view of deployed MS and their relationship Dependency integrity not maintained for un-deployment Platform/Infrastructure Infrastructure management Hierarchical deployment Support for Heterogeneous cloud regions (eg. K8S and Openstack) Maintenance (manual) of chart/values.yaml is not scalable approach for operation Geo-redundancy management support for ONAP components Standardized AAF integration support

Distributed Management (ONAP/3rd Party) - Key Use Cases Analytics/DCAE service at ONAP Edge Closed Loop functions at ONAP Edge Infrastructure LCM across distributed platform (Note 1) Support 3rd party Management component LCM across multiple site Geo-redundancy management support for ONAP components Note 1: Infrastructure LCM – bring up necessary mgmt. K8S clusters only if needed

Analytics (3rd Party) Use Case – Exemplary Deployment Scenario Management Orchestration One training app consists of three services, expected to run in a sequence (DAG based flow requirement) One app requires multiple components in various regions Site Site Training App2 Training App3 Training App1 Visualization Very few Training stack Training stack Model Repo When new workload is brought up, need for configuring existing collection, and inferencing app (Day2 config as a bundle) that are in various regions. (may also require new inferencing app) Site Site Site Inferencing app Inferencing Apps Inferencing Apps In hundreds Inferencing stack Inferencing stack Inferencing stack Site Site Site Site Placement of compute intensive services on nodes that have HW accelerators (GPU, FPGA etc…) Custom Collection service 10s of thousand Collection stack Collection stack Collection stack Collection stack

Options Considered for OOM+ Management Application as traditional VNF package (Option #1) To be part of ONAP Central (Running on same K8S Cluster) To share SDC for management app onboarding To share SO for instantiation of management apps as network services To share OOF for placement decisions based on various criteria including cost, HPA etc… To share MC to bring up management apps in various cloud regions Extending DCAE Orchestration for Tosca and Helm (Option#2) Support Central, regional, edge sites equally as far as management apps are concerned Support controller components to be brought up on its own K8S cluster/namespace Cloudify as service orchestrator and supports Tosca workflow Extend dynamic configuration support for Helm deployed components (supported for Tosca based component) Extend support for design flow and configuration modelling for Helm based components. Support Edge/Site provisioning Extend Dashboard and inventory to include management apps deployed on both Helm and Tosca. Support Cloud-native management applications (that leverage Operators, ISTIO, CRDs for Day0 and Day2 config) Extending Cloud Native Ecosystem with ONAP specific functions (Option#3) Support Central, regional, edge sites equally as far as management apps are concerned Use K8S + some active components to acts as service orchestrator Support controller components to be brought up on its own K8S cluster/namespace Build new active components to support dynamic deployment across multiple K8S clusters and dynamic configuration management (Day 2) Align with existing ONAP components for onboarding/configuration modelling (Design flow) Support Cloud-native management applications (that leverage Operators, ISTIO, CRDs for Day0 and Day2 config) Build new entity for support of Tosca based application (backward compatibility) Build new UI for viewing components running across different cluster Option 1 is ruled out for following reasons Not able to support Cloudify-TOSCA based management applications (existing ones) Separation of concerns raising from using some components between VNFs and management apps

Combined OOM+ solution - Merging of Option 2 & Option 3 – In Progress Key Aspects Leverage Cloud Native Ecosystem Operators, CRDs, Istio Service Mesh etc. Support TOSCA Backward compatibility for existing management applications Support Multiple Deployment Models Standalone (Helm and/or TOSCA) SDC (Helm and/or TOSCA) Leverage specific Cloudify components Discussions in progress with Cloudify team