...
Management Apps as traditional Apps/VNFs - Option 1 | AT&T EOM - Option 2 | Cloud Native K8S Ecosystem (which includes current OOM helm charts ) - Option 3 |
|---|---|---|
Existing infrastructure that is available in ONAP | EOM: ECOMP Subsystem that deploys and | Cloud Native K8S Ecosystem - https://landscape.cncf.io/ ONAP OOM Project - Prescriptive Helm Charts for various ONAP management plane components |
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
- Option 1 Pros (with respect to other options)
- 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
| Category | Requirement Item | Priority | Added by | Modified by and modification | AT&T EOM Mapping (Option 2) | Cloud Native K8S Ecosystem (which includes current OOM helm charts ) Mapping (Option 3) | 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 | Critical | ||||||||
| 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 | |||||||
...