...
- 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 around M1
- 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) based on the usecase requirement
- Setup Jenkins job (under ci-management repo) for building artifacts/docker images. 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 60% (updated 2/2011/4/19 for Frankfurt) (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 Updated 1/12: For Dublin, all dynamic DCAE MS should be onboarded through SDC (which include models/blueprint generation from SDC and distributed into DCAE/CLAMP/Policy)
...
MOD Integration (Design support)
This has to be coordinated with SDC team esp if components has dynamic policy and required CLAMP/Policy integration. This step allows Tosca models to be generated via DCAE-DS/Tosca_Lab tool that will be used in service composition and distribution to Policy/CLAMP and DCAEFor Frankurt, MicroService and Onboarding (MOD) is being introduced in DCAE. All DCAE mS will require to be onboarded through MOD. The pre-requisite for onboarding will similar as before i.e MS owner should create component_spec and policy_model if any required.
Blueprint creation/test (Test)
If the component are onboarded via SDC MOD flow, the blueprints will be generated by TOSCAlab tools contained with DCAE-DS in SDCduring distribution from MOD. Alternatively the components developer can hand-craft the blueprints and testor use bp-gen tool to generate the cloudify blueprint for deployment based on the spec file. This blueprint can be used for testing and integration. The blueprint created manually if required to included part of DCAE static deployment, then blueprint itself should be templatized and added into this repo - https://gerrit.onap.org/r/#/admin/projects/dcaegen2/platform/blueprints. The blueprint can tested on any DCAE deployment by executing into DCAE bootstrap pod (Cloudify Blueprint validation under OOM) For component deployed dynamically on-demand, the blueprint and spec should be stored under corresponding MS repo under dpo/spec and dpo/blueprint directory.
ConfigBindingService Integration (Code enhancement required)
...