ONAP DCAE

All major releases are tagged in gerrit and the artifacts are stored with the release information on onap.nexus. So we can access all old versions of the artifact. If and when a upgrade requires certain steps to be followed they are being added to the release documents as needed https://gerrit.onap.org

Jira is used to track issues. https://wiki.onap.org/display/DW/Tracking+Issues+with+JIRA

Vulnerabilities can be reported using the link https://wiki.onap.org/pages/viewpage.action?pageId=6591711 Currently we don't have any vulnerabilities reported, but the wiki page explains on how to report a vulnerability and how to report anonymously if you do not want the credit for it.

Vulnerabilities handling is documented in https://wiki.onap.org/pages/viewpage.action?pageId=6591711

Coding style is defined in https://wiki.onap.org/display/DW/Java+code+style

DCAE project utilizes the ONAP checkstyle using the Maven maven-checkstyle-plugin for java project and pylint for python components

DCAE has no native binaries

DCAE has no native binaries

Each DCAE components has unique build job as defined under https://git.onap.org/ci-management/tree/jjb/dcaegen2

All releases are tagged in gerrit(git), and the builds are controlled using jenkins. By providing the git tag information the same image can be build over and over again with same bit-for-bit result.

helm deploy onap helm undeploy onap

helm has no optional destination directories, but does let you direct pods to particular worker nodes

The ONAP components require only java and maven to begin with for a developer to quickly install and test ONAP. Even for deployment using OOM and the right amount of resources, we can deploy the full AAI/ONAP suite in less than a day. The steps are documented in https://onap.readthedocs.io/en/latest/submodules/oom.git/docs/oom_quickstart_guide.html

External dependencies are controlled using the pom file, which can be found in the root folder for each of the sub-projects, such as https://gerrit.onap.org/r/gitweb?p=dcaegen2/configbinding.git;a=tree;h=refs/heads/master;hb=refs/heads/master

NexusIQ sonar scan is run on all the projects on a weekly basis

External components are maintained through Maven. The user can get a list of all included components using the maven dependency tree and can update or reuse as they see fit

We avoid depending on deprecated/obsolete functions.

Automatic test suites are run every time before merging the code. The code check in cannot pass with out jenkins posting a +1 on the review.

When regressions occur, we add tests for them.

Majority of DCAE project have code coverage over 80% - https://sonarcloud.io/organizations/onap/projects?search=dcaegen2&sort=-coverage; cumulative coverage across all component is >80%. Continued progress is being made for all components to improve further.

Contributing guide lines for development is recorded in https://wiki.onap.org/display/DW/Development+Procedures+and+Policies

This is documented on our wiki on Code Coverage and Static Code Analysis: https://wiki.onap.org/display/DW/Code+Coverage+and+Static+Code+Analysis and https://wiki.onap.org/display/DW/Creating+a+CSIT+Test

Review/approval process includes validating verify jobs for dcaegen2 project - https://jenkins.onap.org/view/dcaegen2/

DCAE Team follows secure design principles and validates them as part of gerrit-reviews.

Certificates are managed through AAF micro-service which will be deployed with ONAP suite

Authentication configuration are maintained part of OOM helm template and actual credentials are delivered at deployment time as configuration via k8s secret. The certifactes/keys are generated at deployment time from AAF container and stored under different directory and mounted for app container.

All platform component and DCAE services interfaces are switched to TLS. The projects supports secure TLS and HTTPS and Insecure protocols are disabled by default in these applications, they cab be over-ridden by user configuration

all TLS libraries are current

DCAE cert distribution is documented here https://docs.onap.org/en/latest/submodules/dcaegen2.git/docs/sections/tls_enablement.html https://docs.onap.org/en/latest/submodules/dcaegen2.git/docs/sections/services/ves-http/tls-authentication.html

For all components enabled for TLS, certificate validation is done before prior to exchange of private information during the hand-shake.

All release artifacts are signed by the Linux Foundation prior to release.

All release artifacts are signed by the Linux Foundation prior to release.

DCAE Platform - Complaint (Dashboard/Deployment Handler provides API's and data validation is done based on workflow involved. Bad data will result in workflow failure and return 400/500 error code) DCAE Services (collectors) - N/A. Collectors include basic schema validation and required to accept any data sent from xNF (data analysis are done based on event flow and analytics/correlation functions involved)

The security design and assurance case can be found at https://wiki.onap.org/display/DW/DCAE+Security+Design+&+Assurance (permalink https://wiki.onap.org/x/GokDBg). The SECCOM project wikis document all our security vulnerabilities. The release notes in the documentation also provides list of fixes done per release. https://docs.onap.org/projects/onap-dcaegen2/en/latest/sections/release-notes.html

Sonatype CLM scan is applied for static code and dependency security vulnerability reporting. Its results are available on https://nexus-iq.wl.linuxfoundation.org/assets/index.html. The reports contained details of the vulnerabilities and suggestions of fixes.

DCAEGEN2 components are implemented in Java, JavaScript, Cloujour, Python, and Erlang. Not using C or C++.