Page History

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.

Onboarded application artifact stored in DCAE inventory (ready for instantiation)

Yes

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

Supported through DCAE, SDC (DS)

Through Cloudify/Tosca models - different components can be linked and deployed as single entity in dynamic fashion.

Yes

(SDC has a way to provide licensing information)

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)

Yes

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

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)

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.

Work in Dublin - Target edge cloud (with right credentials maintained in ONAP central) will be provided as input to deployment

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.

Yes

(SO provides API at various granularity)

Existing capability.

Supported under both Tosca and Helm.

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

Functionality can be built to support based on AAI event as future enhancement.

There are 2 options.

1. The management applications that are directly related to instantiation and termination of a Service (VNFs) are an extension of the Service. Therefore it makes sense that the management applications (Helm Charts) under this scenario should remain as part of the Service Orchestration flow.
   
   
2. Alternatively, the Cloud Native approach would be to deploy all needed management applications to the cloud region but with a replicaCount=0. Only the specifications for the management applications are stored (etcd). No other resources are consumed until its replicaCount becomes > 0. This would happen in response to a monitored metric that is set (or increases) when a VNF is deployed. Likewise the management application would free all consumed resources and return to its dormant state (replicaCount=0) once the monitored metric clears (or reduces) after VNF is terminated. Horizontal scalability and the Custom Metric APIs, are existing Kubernetes capabilities.

Yes

(SDC supports adding default Day0 configuration of workloads)

Existing capability

Day0 configuration can be provided part of designer or operator as input.

Yes

(SDC supports multiple Day0 profles - either through customization or as artifacts in case of K8S)

Yes

Supported through Policy/DCAE for Tosca work flow.

Helm chart configuration update supported via custom helm plugin

Yes

(SO can talk to OOF to get the right flavor for workloads in a VFM)

Not currently exist for Tosca workflow.

Helm charts supported.

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

Supported through Policy/DCAE for Tosca work flow.

Helm chart configuration update supported via custom helm plugin

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

Supported through Policy/DCAE for Tosca work flow.

Helm chart configuration update supported via custom helm plugin

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)

Functionality supported under current design; for Tosca workflow installed component but not currently exist in ONAP.

The Cloud Native approach would be to deploy all needed management applications to the cloud region but with a replicaCount=0. Only the specifications for the management applications are stored (etcd). No other resources are consumed until its replicaCount becomes > 0. This would happen in response to a monitored metric that is set (or increases) when a VNF is deployed. Likewise the management application would free all consumed resources and return to its dormant state (replicaCount=0) once the monitored metric clears (or reduces) after VNF is terminated. Horizontal scalability and the Custom Metric APIs, are existing Kubernetes capabilities.

Yes

(Using SSL/TLS)

Supported via securing DMAAP topics.

Platform support dynamic topic creation and AAF role assignment using DMAAP DBCL

N/A

This is an application requirement and not a requirement of the Platform Orchestrator.

Application needs to support SSL/TLS.

Yes

(No restriction. it is based on management application)

N/A

This is an application requirement and not a requirement of the Platform Orchestrator.

Partial

(Same monitoring schemes as available for VNFs, but suggest that all management components acts prometheus target)

Cloudify UI provides the relation of the multiple MS (based on node types).

Consul integration supported

Dashboard - Provides unified console for Operation to check/manage deployment of application

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)

Existing capability

(relies on k8s)

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)

Existing capability; supported for both Tosca and Helm

(relies on k8s)

Yes

(It is part of K8S)

Existing capability; supported for both Tosca and Helm

(relies on k8s)

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.

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)

Yes

(Using K8S plugin)

Yes

(Using K8S plugin)