Team:
Lead:
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 <simone.mangiante@vodafone.com>, 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:
- 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
- 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 (SDC, SO, OOF etc.)
- 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
- Currently, Multiple Orchestrators for Management Workloads (SDC, SO, OOF etc.)
- Managed Workloads
- 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
- Leverage K8S (Operators, Custom Resource Definitions etc.) for Distributed Systems Management
Architectural Deployment Scenarios to consider:
Management Workloads
Deployment Model | Edge using certain ONAP management workload functions as an Offload | |
| Description | Architecture Near-term Priority | |
Edge and Central Provider are same |
| Priority - ? Rationale:
Note: Analytics is currently addressed by a Distributed DCAE Orchestrator based on Cloudify. Participant Operator Priority
|
Edge and Central Providers are different |
| Priority - High? Rationale - Same as above. Participant Operator Priority
|
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
- 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
| Requirement Item | Priority | Added by | Modified by and modification | Mapping to requirements from DCAE team |
|---|---|---|---|---|
| Ability to onboard management applications, that are to be deployed in cloud-regions, in ONAP-Central. Shall not have any expectations that all management applications are onboarded as a single bundle. | high | Allow new MS/applications/components to be onboarded independently | ||
| Ability to compose multiple management applications to be part of one management bundle and defining the dependency graph of applications belonging to a bundle | high | Allow Service assurance flow composition and deployment of individual or group of component | ||
| Ability to deploy management applications in selected cloud regions that are owned by ONAP operator | high | Srinivasa Addepalli | Allow Service assurance flow composition and deployment of individual or group of component | |
| Ability to deploy management applications that are ephemeral (example: Analytics applications) | high | Allow Service assurance flow composition and deployment of individual or group of component | ||
Ability to deploy management applications in selected cloud regions that are not owned by ONAP operator, but has business relationship (Examples: Public Clouds or Edge Clouds owned by some other organization) | low | Srinivasa Addepalli | ||
| Support for deploying management applications independent of each other when there are no dependencies (no expectation that all management applications are brought up together). | high | Allow Service assurance flow composition and deployment of individual or group of component | ||
| Ability to deploy few management applications based on VNF instantiations and bring down when VNF is terminated | high | Dynamic deployment of MS based on xNF instantiation | ||
| Ability to apply configuration (Day0 configuration) of management applications at the time of deployment | high | |||
| Support for various Day0 configuration profiles (e.g. different profiles for different cloud regions w/ differing capabilities) | high | |||
| Support for Day 2 configuration of single or multiple instances of management applications in various cloud regions | high | Srinivasa Addepalli | ||
| Support for management applications depending on other management applications - Support for configuration (Day2 configuration) of provider services when the consuming service is being instantiated and removal of the configuration on provider services when consuming service is terminated (Example: When analytics applications are brought up, analytics/collection framework need to be updated with additional configuration such as DB table, Kafka topic etc..) | high | Srinivasa Addepalli | Dynamic topics provisioning and role assignment for MS | |
| Support for Day 2 configuration (add/delete) of appropriate management applications upon VNF instantiation/termination (Example: configuration of analytics & collection services when VNFs are brought up and removing the added configuration upon VNF termination) | high | Srinivasa Addepalli | Dynamic reconfiguration of MS based on xNF instantiations | |
| Secure connectivity between central ONAP and management applications in cloud regions | high | |||
| Support for various connectivity protocols (Kafka, HTTP 1.1, 2.0, GRPC, Netconf etc...) between ONAP-Central and management components in cloud regions | high | |||
| Monitoring and visualization of management applications of cloud-regions along with ONAP components at the ONAP-Central | high | Complete view of MS and relation maintained at single/multisite K8S scenarios Healthcheck of all deployment component to be available for CLAMP/external system | ||
| Scale-out of management application components at the cloud-regions & traffic (transaction) distribution | high | |||
| Ability to upgrade management application components without loss of functionality | low | |||
| High availability of management applications in the cloud regions | high | |||
| Support for third party management applications that provide similar functionality as ONAP management applications (Modularity) | high | |||
| Support management applications as containers | high | @Srinivasa Addepalli | ||
| Support management applications as VMs | low |
Assumptions
| Item | Added by | Modified by | |
|---|---|---|---|
| ONAP Management components can only be brought up in cloud-regions that are based on Kubernetes | |||
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.
Input Requirements:
- DCAE Platform Requirements: https://wiki.onap.org/download/attachments/28379482/DCAE%20Platform%20Requirements.pptx?api=v2
Definitions:
Architectural Options:
Conclusion:
Other Deliverables:
LF blog and Architecture white paper during ONS time frame.