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 , 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.
- 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.
- 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
- 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 Note: In this context, Offload is the process of moving certain functions from central to edge locations to address various requirements such a WAN bandwidth constraint, higher resiliency, real-time service assurance etc. | |
| 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 Note: In this case, Central provider is still managing the management functionality running at the edge, but using another operators infrastructure. |
Note: A Virtual Private Cloud (VPC) provides a dedicated pool of compute/network/storage resources using a infrastructure as a service approach. | Same as above. Vodafone (question): should this model be at a lower priority? For a first phase it's sufficient to enable the case where edge and central providers are the same. |
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
| Category | Requirement Item | Priority | Added by | Modified by and modification | AT&T EOM Mapping | K8S Ecosystem Mapping | DCAE Analytics Mapping | |||
|---|---|---|---|---|---|---|---|---|---|---|
| Open source Current | Open source in progress (approx. timeline desired) | Open source Current | Open source in progress (approx. timeline desired) | Requirements | Current Implementation Status | |||||
| Onboarding | 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 | Supported through DCAE, SDC*, Policy, CLAMP | ||||||
| Onboarding | 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 | Supported through DCAE, SDC*, CLAMP | ||||||
| Onboarding | Shall have a way to specific licensing options for third party management applications (similar to VNF licensing) | high | Srinivasa Addepalli | |||||||
| Instantiation | Ability to deploy management applications in selected cloud regions that are owned by ONAP operator | high | Allow Service assurance flow composition and deployment of individual or group of component | DCAE (WIP) | ||||||
| Instantiation | 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 | DCAE (Yes) | ||||||
| Instantiation | 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 | DCAE (WIP) | |||||||
| Instantiation | 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 | DCAE (Yes) | ||||||
| Instantiation | 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 | DCAE (Partial - can be manually triggered from CLAMP) | ||||||
| Instantiation | Ability to apply configuration (Day0 configuration) of management applications at the time of deployment | high | DCAE (Yes) | |||||||
| Instantiation | Support for various Day0 configuration profiles (e.g. different profiles for different cloud regions w/ differing capabilities) | high | Supported through Policy/DCAE | |||||||
| Instantiation | Support for placement of management applications based on platform features (example: GPU, FPGA etc...) | high | DCAE (No) | |||||||
| Instantiation | Support for consistent Day0 configuration mechanisms - should be the same path as Day 2. | high | Vijay Venkatesh Kumar | DCAE(Yes) | ||||||
| Run time | Support for Day 2 configuration of single or multiple instances of management applications in various cloud regions | high | DCAE (Yes) | |||||||
| Run time | 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 | Dynamic topics(MR) and feeds(DR) provisioning and role assignment for MS | DCAE (Partial) | ||||||
| Run time | 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 | Dynamic reconfiguration of MS based on xNF instantiations | DCAE (Functionality supported; but not currently exist in ONAP) | ||||||
| Run time | Support for consistent Day 2 configurations across management components - should be the same path as Day 0. | high | DCAE (Yes) | |||||||
| Networking | Secure connectivity between central ONAP and management applications in cloud regions | high | DCAE (Partial) and dependent on DMAAP | |||||||
| Networking | Support for various connectivity protocols (Kafka, HTTP 1.1, 2.0, GRPC, Netconf etc...) between ONAP-Central and management components in cloud regions | high | DCAE (Partial) | |||||||
| Run time | 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 | DCAE (Yes) | ||||||
| Run time | Scale-out of management application components at the cloud-regions & traffic (transaction) distribution | high | DCAE (Yes relies on k8s) | |||||||
| Run time | Ability to upgrade management application components without loss of functionality | low | DCAE (Yes; relies on k8s) | |||||||
| Run time | High availability of management applications in the cloud regions | high | DCAE (Yes; relies on k8s) | |||||||
| Miscellaneous | Support for ONAP-compliant third party management applications that provide similar functionality as ONAP management applications.
| high | ramki krishnan | If complying to Onboarding requirements (#1)- DCAE (Y) | ||||||
| Miscellaneous | Support management applications as containers | high | @Srinivasa Addepalli | DCAE (Yes) | ||||||
| Miscellaneous | Support management applications as VMs | low | DCAE (Yes) | |||||||
| Security | Security and privacy aspects of management applications (To be expanded) | high | ||||||||
| Instantiation | Support for MS deployment not binded to any VNF/service; these are application which are service agnostic can be managed by dynamic configuration rule to support different usecases | DCAE (yes) | ||||||||
| Miscellaneous | Backward compatibility with existing application based on TOSCA | |||||||||
| Miscellaneous | Single orchestrator for both managed (VNFs/Apps) and management applications that are to be deployed in cloud-regions | low (but highly preferred) | Srinivasa Addepalli | |||||||
Assumptions
| Item | Added by | Modified by | |
|---|---|---|---|
| ONAP Management components can only be brought up in cloud-regions that are based on Kubernetes | |||
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.