Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

CategoryRequirement ItemPriorityAdded 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)

AT&T EOM Mapping (Option 2)Cloud Native K8S Ecosystem (which includes current OOM helm charts ) Mapping (Option 3)DCAE Analytics Mapping
Open source CurrentOpen source in progress (approx. timeline desired)Open source CurrentOpen source in progress (approx. timeline desired)RequirementsCurrent Implementation Status
OnboardingAbility 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)





Allow new MS/applications/components to be onboarded independently

Supported through DCAE, SDC*, Policy, CLAMP
OnboardingAbility to compose multiple management applications to be part of one management bundle and defining the dependency graph of applications belonging to a bundlehigh

Yes

(SDC now supports Helm, based description. It is possible to introduce dependency via initContainers and helm hooks)





Allow Service assurance flow composition and deployment of individual or group of componentSupported through DCAE, SDC*, CLAMP
OnboardingShall have a way to specific licensing options for third party management applications (similar to VNF licensing)highSrinivasa Addepalli

Yes

(SDC has a way to provide licensing information)







InstantiationAbility to deploy management applications in selected cloud regions that are owned by ONAP operatorhigh

Partially

(SO has ability to select the cloud-region while deploying the VNF. But there is no bulk deployment by selecting multiple cloud regions.It require enhancements. But we believe this requirement is needed for NFs too)





Allow Service assurance flow composition and deployment of individual or group of componentDCAE (WIP)
InstantiationAbility to deploy management applications that are ephemeral (example: Analytics applications)high

Yes

(Complete control at the SO. One can terminate the VNF/VFM at any time)





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

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)






DCAE (WIP)
InstantiationSupport 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)





Allow Service assurance flow composition and deployment of individual or group of componentDCAE (Yes)
InstantiationAbility to deploy few management applications based on VNF instantiations and bring down when VNF is terminatedhigh

Yes

(SDC/SO with their bundling approaches - management app can be added as VFC in a VNF or as a VNF in a service)





Dynamic deployment of MS based on xNF instantiationDCAE (Partial - can be manually triggered from CLAMP)
InstantiationAbility to apply configuration (Day0 configuration) of management applications at the time of deploymenthigh

Yes

(SDC supports adding default Day0 configuration of workloads)






DCAE  (Yes)
InstantiationSupport 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)






Supported through Policy/DCAE
InstantiationSupport 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)






DCAE (No)
InstantiationSupport for consistent Day0 configuration mechanisms - should be the same path as Day 2.highVijay 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)






DCAE(Yes)
Run timeSupport for Day 2 configuration of single or multiple instances of management applications in various cloud regionshigh

Yes

(APPC support for Day2 configuration. Also Day2 configuration support in K8S plugin - Ongoing. One can select cloud-region, instance while applying Day2 configuration)






DCAE (Yes)
Run timeSupport 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)





Dynamic topics(MR)  and feeds(DR) provisioning and role assignment for MS

DCAE (Partial)
Run timeSupport 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)highWIP



Dynamic reconfiguration of MS based on xNF instantiations

DCAE (Functionality supported; but not currently exist in ONAP)
NetworkingSecure connectivity between central ONAP and management applications in cloud regionshigh

Yes

(Using SSL/TLS)






DCAE (Partial) and dependent on DMAAP
NetworkingSupport for various connectivity protocols (Kafka, HTTP 1.1, 2.0, GRPC, Netconf etc...) between ONAP-Central and management components in cloud regionshigh

Yes

(No restriction. it is based on management application)






DCAE (Partial)
Run timeMonitoring and visualization of management applications of cloud-regions along with ONAP components at the ONAP-Centralhigh

Partial

(Same monitoring schemes as available for VNFs)





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 timeScale-out of management application components at the cloud-regions & traffic (transaction) distributionhigh

No

(This work is slated for Release E)






DCAE (Yes relies on k8s)
Run timeAbility to upgrade management application components without loss of functionalitylow

No

(This work is slated for Release E)






DCAE (Yes; relies on k8s)
Run timeHigh availability of management applications in the cloud regionshigh

Yes

(It is part of K8S)






DCAE (Yes; relies on k8s)
Miscellaneous

Support for ONAP-compliant third party management applications that provide similar functionality as ONAP management applications.

  • Some of the key aspects of ONAP-compliance include but are not limited to the following - API compatibility, Cloud Native Packaging in ONAP Helm chart format etc.
high

Yes

(As long as third party management applications are described using Helm)






If complying to Onboarding requirements (#1)- DCAE (Y)
MiscellaneousSupport management applications as containershigh@Srinivasa Addepalli

Yes

(Using K8S plugin)






DCAE (Yes)
MiscellaneousSupport management applications as VMslow

Yes

(Using K8S plugin)






DCAE (Yes)
SecuritySecurity and privacy aspects of management applications (To be expanded)high
It is generic requirement and to be taken care outside of this work item





InstantiationSupport 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)






DCAE (yes)
 MiscellaneousBackward compatibility with existing application based on TOSCA Critical No



  
MiscellaneousSingle orchestrator for both managed (VNFs/Apps) and management applications that are to be deployed in cloud-regionslow (but highly preferred)Srinivasa AddepalliYes





...