Backup

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

@Srinivasa Addepalli

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)

Existing OOM functionality.

Same mechanism used to deploy helm charts in ONAP Central is used to deploy helm charts to cloud regions.

Open

Open

N/A

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

@Srinivasa Addepalli

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)

Existing OOM functionality.

Customization of components to deploy is defined in configuration override files (such as cloud-2.yaml).

Dependencies defined in application Helm Charts.

N/A

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

@Srinivasa Addepalli

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

Existing OOM functionality.

Cloud regions are defined in onap-central as kube configs. Iterate over each cloud-region and deploy common components. Can be scripted if desired.

Question: Should upgrades of cloud regions be under central control or regional control (ie. via edge stacks such as Akranio)?

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

@Srinivasa Addepalli

Yes

(Complete control at the SO. One can terminate the management application bundle at any time)

Yes

Existing OOM functionality.

Terminate deployed application by setting 'enabled' flags to false

• in override file (e.g. cloud.yaml)

• using --set option

• using helm undeploy
  
  

N/A

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

@Srinivasa Addepalli

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

Existing OOM functionality.

Cloud regions are defined in onap-central as kube configs. Kube configs already contain credentials for communicating with any cloud region - public, private and regardless of ownership model.

N/A

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

@Srinivasa Addepalli

Yes

(SO provides API at various granularity)

Yes

Existing OOM functionality.

Deploy individual applications by setting 'enabled' flags to true

• in override file (e.g. cloud.yaml)

• using --set option
  
  

N/A

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

@Srinivasa Addepalli

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

@Srinivasa Addepalli

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

@Srinivasa Addepalli

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

@Srinivasa Addepalli

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

@Srinivasa Addepalli

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

@Srinivasa Addepalli

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

@Srinivasa Addepalli

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

@Srinivasa Addepalli

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

@Srinivasa Addepalli

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

@Srinivasa Addepalli

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

@Srinivasa Addepalli

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

@Srinivasa Addepalli

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

@Srinivasa Addepalli

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.

• 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

@Srinivasa Addepalli

@Ramki Krishnan

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

@Srinivasa Addepalli

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

@Shrikant Acharya

@Vijay Kumar

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

@Vijay Kumar

 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.