| Table of Contents |
|---|
This document describes how to develop and general pre-requisites for DCAEGEN2 sub-components; Topics that are generic across ONAP are not covered by this document,
DCAE platform is microservice centric, the services (collectors and analytics interfacing with NF events) themselves can be build independently and integrated with DCAE with minimal work. However as ONAP itself requiring carrier grade level, all components has strict S3P goals and LF process to comply.
Overview
Typically DCAE sub-components are developed individually under their own ONAP Gerrit/Git repos. The initiation of a new repo generally starts during the release planning time, which usually starts around the code freeze time of the previous ONAP release. Normally before the functionality freeze time (M2), projects that are planned to be included in a release are determined, and infrastructure items such as repo creation for new projects are completed.
Pre-requisites for Integration
...
- Review new service proposal with architecture team and project team. If new collectors, this typically requires review with ARC and VNFREQ team as this introduces new interface between xNF and DCAE.
- Identify usecase this service will be targeted under (optional).
- Capture external and internal dependencies and api consumed/provided.
- Repository creation (PTL will submit request to RM, who will coordinate with TSC/LF support)
- Work with PTL to scope the service and EPIC/US creations and release/sprints to target
- Push seed code (if available) into gerrit
- Reference this ONAP WiKi page for details of configuring for using Gerrit: Configuring Gerrit.
- Build/enhance functional component (mS)
- Setup Jenkins job (under ci-management repo) for building artifacts/docker images.
ONAP uses Jenkins based CICD tool chain. However, contributors are only given read access to the Jenkins servers. All jobs are created by automatic generation from JJB definitions. As a DCAE contributor, to create new Jenkins job will require a new JJB file being created under the jjb/dcaegen2 directory of the ci-managerment project. The status of Jenkins jobs can be viewed at http://jenkins.onap.org.
- Perform CLM/coverty scan and address all CRITICAL/HIGH License/security issues identified (Required for passing release candidate)
- Define CSIT test (How to guide → Creating a CSIT Test)
- Code Coverage - Min 55% (Required for passing release candidate)
- Logging compliance (https://wiki.onap.org/pages/viewpage.action?pageId=28378955) (Required for passing release candidate)
- If API's are exposed, need to conform to ONAP API Common Versioning Strategy (CVS) Guidelines
Note: All above are general ONAP requirements for any new contributions.
...
If the component is stateful, it should persist its state on external store (eg. pg, redis) to allow support for scaling and resiliency. This should be important design criteria for the component. If the component fails to meet S3P goals, it will not be release candidate. And if the components either publish/subscribe into DMAAP topic, then secure connection to DMAAP must be supported (platform will provide aaf_username/aaf_password for each topic as configuration).
Code Requirements
- License text included in each file. Apache 2 for coding files; CC4 for others.
- The Copyright line for contributing organization inserted or updated reflecting the contribution year.
- A LICENSE.txt file placed at the root of the repo to provide umbrella coverage.
- Unit testing coverage > 52% for R4
- For Java and Python code, coverage reporting: http://sonar.onap.org.
- For other languages, coverage reporting done in language native method.
- CLM reporting free of critical vulnerabilities for both security and licensing. CLM reports available at: https://nexus-iq.wl.linuxfoundation.org/assets/index.html
Documentation
DCAE WIKI
The project wiki space (https://wiki.onap.org/display/DW/DCAE+Documentation) can be used to documents general design about the components itself; can serve the community to know about the component itself and point to other repo/release documentation.
...
Once the components meet all above criteria, the component will be included in the DCAE bootstrap process to enable deployment during ONAP/DCAE instantiation (this step is optional if component will be deployed through CLAMP).
Artifact Requirements
There are two levels of artifacts that will be built from ONAP source codes:
- Software component
- jar, war, wheel/pypi, wagon, etc.
- Docker container
It is generally expected that each functional entity of DCAE project to be available and packaged into Docker images. Docker versioning guideline can be found at .
CSIT testing
CSIT is an integrated automatic testing practice of ONAP for container level testing. It is expected that component contributors to implement CSIT testing plans for their components so that basic component level integrity can be tested. More information regarding CSIT testing can be found at: Creating a CSIT Test.
Bug reporting
Bugs are tracked using the ONAP JIRA system available under the DCAE project: https://jira.onap.org/secure/RapidBoard.jspa?rapidView=49&view=planning.nodetail
Resources
JJB - https://wiki.onap.org/display/DW/Using+Standard+Jenkins+Job+%28JJB%29+Templates
CSIT - Creating a CSIT Test
Documentation - 2017-09-19 Documentation Tutorial, Further information regarding documentation can also be found here: http://onap.readthedocs.io/en/latest/index.html.