...
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
...
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
No change is envisioned in the workload instantiation from a ONAP user perspective.
...
Management application: Can be ONAP component or equivalent component from third parties
Solution Options
Management Apps as traditional Apps/VNFs - Option 1 |
|---|
| Extending DCAE Orchestration (OOM-Tosca) - Option 2 | Cloud Native K8S Ecosystem (which includes current OOM helm charts ) - Option 3 |
|---|---|
Existing infrastructure that is available in ONAP |
•Use SDC for onboarding management applications if they are independent of VNF Or make management app also part of VNF if it needs to be dynamic |
•Use SO to bring up the management app like any other VNF |
•Leverage MC for talking to various cloud-regions of different technologies (Management App as VM or container or public cloud entity) |
•Leverage OOF to make placement decisions (such as HPA, affinity, anti-affinity) |
manages the lifecycle of ECOMP and all
software required to make it operational,
including scaling and self-healing
▪ EOM merges the functionality of:
▪ ECOMP-C developed by AT&T
▪ DCAE-C developed by AT&T
▪ DCAE-C from ONAP
▪ ONAP OOM (TOSCA) & HELM Plugin
▪ CCSDK (ONAP)
▪ Single code base
▪ Continuous process of insourcing / opensourcing between ONAP and EOM
Using Existing DCAE orchestration to deploy and manage lifecycle for all management application (central and edge) DCAE orchestration supports deployments of Ms (collectors, and analytics services); primary orchestrator is cloudify. The current orchestration can be extended for supporting deployment of helm charts and Tosca_blueprints to deploy wide ranges of managed applications/services at multiple sites. | 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
...
Requirements and Narrowed-down Solution Options Mapping
| Category | Requirement Item | Priority | Added by | Management Apps as traditional Apps/VNFs - Option 1 (Not considered as it is not satisfying the critical requirement of supporting existing Cloudify-TOSCA based management applications) |
|---|
Extending DCAE Orchestration (OOM-Tosca) - Option 2 |
|---|
| Cloud Native K8S Ecosystem (which includes current OOM helm charts ) Mapping (Option 3) | DCAE Analytics Mapping | |||
|---|---|---|---|---|
| (source for management appl requirements) | |
|---|---|
| Current status | Future work planned |
| (approx. timeline desired) |
| Current |
| status | Future work planned |
| (approx. timeline desired) |
| 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 | Yes (Using SDC. SDC allows to define it as VNF with multiple management applications as VNFCs. SDC allows multiple VNFs in a service and there could be multiple services) | Supported through DCAE, SDC*, Policy, CLAMP | SDC Design tool enhancement (E release) | Allow new MS/applications/components to be onboarded independently |
| 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 | Yes (SDC now supports Helm, based description. It is |
possible to introduce dependency via initContainers and helm hooks) | Supported through DCAE, SDC (DS) | SDC Design tool enhancement (E release) | Allow Service assurance flow composition and deployment of individual or group of component |
| Onboarding | Shall have a way to specify licensing options for third party management applications (similar to VNF licensing) | high | Srinivasa Addepalli | Yes (SDC has a way to provide licensing information) | TBA | ||||
| Instantiation | Ability to deploy management applications in selected cloud regions that are owned by ONAP operator | high | Partially (SO has ability to select the cloud-region while deploying the VNF and hence same is applicable for management applications. But there is no bulk deployment by selecting multiple cloud regions.It require enhancements. But we believe this requirement is needed for NFs too) | Supported by design; need further work to identify the cloud-region part of deployment | k8s Plugin enhancement worked as stretch goal for Dublin | Allow Service assurance flow composition and deployment of individual or group |
| of component | |||||||||
| Instantiation | Ability to deploy management applications that are ephemeral (example: Analytics applications) | high | Yes (Complete control at the SO. One can terminate the management application bundle at any time) | Yes | Allow Service assurance flow composition and deployment of individual or group of component |
| 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 | Yes (Multi-Cloud has ability to deploy workloads in any cloud-region - whether owned by operators or even public clouds as long as right credentials are used) |
| Supported by design; need further work to identify target edge cloud (with right credentials maintained in ONAP central) | TBD | ||||||||
| 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 | Yes (SO provides API at various granularity) | Yes | Allow Service assurance flow composition and deployment of individual or group of component |
| Instantiation | Ability to deploy few management applications based on VNF instantiations and bring down when VNF is terminated | high | Yes (SDC/SO with their bundling approaches - management app can be added as VFC in a VNF or as a VNF in a |
service) | Can be triggered from CLAMP | Add new service based on topology interface notification to trigger MS deployment | Dynamic deployment of MS based on xNF instantiation |
| Instantiation | Ability to apply configuration (Day0 configuration) of management applications at the time of deployment | high | Yes (SDC supports adding default Day0 configuration of workloads) |
| Yes |
| Instantiation | Support for various Day0 configuration profiles (e.g. different profiles for different cloud regions w/ differing capabilities) | high | Yes (SDC supports multiple Day0 profles - either through customization or as artifacts in case of K8S) | Yes (Supported through Policy/DCAE) | |||||
| Instantiation | Support for placement of management applications based on platform features (example: GPU, FPGA etc...) | high | Yes (SO can talk to OOF to get the right flavor for workloads in a VFM) |
| Not currently | Can be enhanced to interface with OOF to determine required placement |
| Instantiation | Support for consistent Day0 configuration mechanisms - should be the same path as Day 2. | high | Vijay Venkatesh Kumar | Yes (Work is going on in K8S plugin to ensure that Day 2 configuration is also supported as Helm charts as Day0 configuration. This is made possible due to microservices supporting K8S operators for their configurations) |
| Yes |
| Run time | Support for Day 2 configuration of single or multiple instances of management applications in various cloud regions | high | Yes (APPC support for Day2 configuration. Also Day2 configuration support in K8S plugin - Ongoing. One can select cloud-region, instance while applying Day2 configuration) |
| 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 | Yes (In case of K8S world, as long as day2 configuration is also supported via K8S resources, it is possible. K8s |
Plugin does support this) | Supported under current design. Interface with DMAAP BC through plugin being worked for Dublin | Dynamic topics(MR) and feeds(DR) provisioning and role assignment for MS |
| 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 | WIP | Functionality supported under current design; but not currently exist in ONAP. | Add new service based on topology interface notification to trigger MS reconfiguration | Dynamic reconfiguration of MS based on xNF instantiations |
| Networking | Secure connectivity between central ONAP and management applications in cloud regions | high | Yes (Using SSL/TLS) |
| Supported via securing DMAAP topics | ||||
| 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 | Yes (No restriction. it is based on management application) |
| Interface between Central and edge supported primarily via DMAAP | |||||||||
| Run time | Monitoring and visualization of management applications of cloud-regions along with ONAP components at the ONAP-Central | high | Partial (Same monitoring schemes as available for VNFs, but suggest that all management components acts prometheus target) | Yes | Complete view of MS and relation maintained at single/multisite K8S scenarios Healthcheck of all deployment component to be available for CLAMP/external system |
| Run time | Scale-out of management application components at the cloud-regions & traffic (transaction) distribution | high | Yes (but testing is required with a use case to ensure that there are no gaps) (This work is slated for Release E - configuration of ISTIO for L7 workloads and NSM for L2/L3/L4 workloads) Even though K8S can bring up more instances, traffic distribution is expected to be configure properly) | Yes |
( |
relies on k8s) | |||||
| Run time | Ability to upgrade management application components without loss of functionality | low | Yes ((but testing is required with a use case to ensure that there are no gaps) (This work is slated for Release E - configuration of ISTIO for L7 workloads and NSM for L3/L3/L4 workloads) Loss of functionality requires careful configuration of traffic rules of ISTIO or NSM) | Yes |
( |
relies on k8s) | |||||
| Run time | High availability of management applications in the cloud regions | high | Yes (It is part of K8S) | Yes |
( |
relies on k8s) | ||||
| Miscellaneous | Support for ONAP-compliant third party management applications that provide similar functionality as ONAP management applications.
| high | Yes (As long as third party management applications |
are described using Helm) | Yes (helm chart deployment will be supported via new helm plugin contributed for Dublin (the policy reconfiguration will require complying to onboarding req#1) |
| Miscellaneous | Support management applications as containers | high | @Srinivasa Addepalli | Yes (Using K8S plugin) |
| Yes |
| Miscellaneous | Support management applications as VMs | low | Yes (Using K8S plugin) |
| Yes |
| Security | Security and privacy aspects of management applications (To be expanded) | high | It is generic requirement and to be taken care outside of this work item | TBA | |||||
| 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 | Yes (If management application is not bound to any network function, this can be deployed as a separate VSP) |
| Yes | ||||
| Miscellaneous | Backward compatibility with existing application based on TOSCA in ONAP | Critical | No |
| Yes | |||||||||
| 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 | Yes | Can be supported if vnf/app onboarding can be aligned with current management application flow. |
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.
...