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
Status:
Draft.
Plan to be finalized in Arch. sub committee meeting on 01/15/2018.
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
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) | medium | 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 | 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 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 | |||
Architectural Deployment Scenarios to consider:
Outcome of Edge Automation Discussions on 01/16/2019:
Deploy-ment Model | Non-ONAP Central | ONAP Central | Edge using certain ONAP functions as an Offload Note: In this case, ONAP central is interfacing with edge directly using Multi-Cloud APIs for workload deployment. | Edge using ONAP Orchestration Note: In this case, their is a two (or more) level orchestration hierarchy when ONAP Central is interfacing with ONAP Edge Orchestrator using SO style APIs for workload deployment. | Edge *not* using ONAP Orchestration Note: This assumes at least a two level hierarchy for orchestration - ONAP Central Orchestrator and 3rd party Edge Orchestrator. This is specific to Service (VNF/App) Orchestration and *not* Cloud infrastructure orchestration. Interfacing to cloud infrastructure is already covered through ONAP multi-cloud. | ||||||
Description | Architecture Near-term Priority for VNFs | Architecture Near-term Priority for Apps | Description | Architecture Near-term Priority for VNF Orchestration | Architecture Near-term Priority for App Orchestration | Description | Architecture Near-term Priority for VNF Orchestration | Architecture Near-term Priority for App Orchestration | |||
Edge and Central Provider are same | NA | Yes for all cases |
| Priority - High? Rationale:
Note: Analytics is currently addressed by a Distributed DCAE orchestrator based on Cloudify Participant Operator Priority
| Priority - Medium? Rationale:
Participant Operator Priority
|
| Priority - Medium? Rationale:
Participant Operator Priority
| Priority - Medium? Rationale:
Participant Operator Priority
|
| Priority - Medium? Rationale:
Participant Operator Priority
| Priority - Medium? Rationale:
Participant Operator Priority
|
Edge and Central Providers are different | NA | Yes for all cases | Use Existing VPCs (VPC creation out of scope for ONAP)
| Priority - High? Rationale:
Participant Operator Priority
| Priority - Medium? Rationale:
Participant Operator Priority
| Use Existing VPCs (VPC creation out of scope for ONAP)
| Priority - Medium? Rationale:
Participant Operator Priority
| Priority - Medium? Rationale:
Participant Operator Priority
| Use Existing VPCs (VPC creation out of scope for ONAP)
| Priority - Medium? Rationale:
Participant Operator Priority
| Priority - Medium? Rationale:
Participant Operator Priority
|
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.