| Table of Contents |
|---|
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.
...
- 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.
- Must support Java11 (or higher) or Python 3.x
- 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)
Non-Function requirement
- Must support Java11 (or higher) or Python 3.x (as recommended by SECCOM for targetted release) (Required for passing release candidate)
- Code Coverage - Min 60% (updated 11/4/19 for Frankfurt) (Required for passing release candidate)
Logging compliance (https://wiki.onap.org/pages/viewpage.action?pageId=28378955)- Log to be written into file and stdout(Required for passing release candidate)
- If API's are exposed, need to conform to ONAP API Common Versioning Strategy (CVS) Guidelines
- Containers must have no more than one main process
- Containers must crash properly when a failure occurs
- No hardcoded password in the container (should be made configurable and set at deployment time and sourced using CBS apis')
Note: All above are general ONAP requirements for any new contributions.
Once the service code is delivered and container can be built, follow below DCAE Platform Integration steps
...
Once the main functionality is build and components is executable as docker container/jar - it should be integrated with DCAE platform to enable dynamic instantiation and configuration management by DCAE controller.
Build component spec
...
(Design support)
Every component to be onboarded into DCAE, should prepare a component spec (a.k.a spec) - which is meta data represented in json describing the component configuration model. Details on spec creation and validation can be found here - https://onap.readthedocs.io/en/beijing/submodules/dcaegen2.git/docs/sections/components/component-specification/component-specification.html?highlight=component%20spec
The dcae_cli tools enables MS owner to validate the component spec and data_Formats created and also "test" the deployment of MS itself. This allows components to mimic the configuration returned from ConfigBinding Service as expected on typical cloudify based deployment by DCAE platform (Documentation on spec format and tool usage can be found under https://onap.readthedocs.io/en/beijing/submodules/dcaegen2.git/docs/sections/components/dcae-cli/commands.html?highlight=dcae_cli )
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/Policyunder ONAP.readthedocs (corresponding source in gerrit)
MOD Integration (Design support)
For 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.
Note: For Guilin release MOD onboarding is optional. If the component is deployed independently, blueprint can be generated manually or using the bp-gen tool (described in next step)
Blueprint creation/test (
...
Deployment support)
If the component are onboarded via MOD flow, the blueprints will be generated during distribution from MOD and loaded into DCAE Inventory. Once the blueprint is available inventory, components can be deployed using Dashboard UI.
Alternatively the components developer can hand-craft the blueprints or 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/
All Components identified part of release must have their blueprints added into dcaegen2/platform/blueprints. For component deployed dynamically on-demand, the blueprint and spec should be stored under corresponding MS repo under dpo/spec and dpo/blueprint directory.blueprint repository. DCAE-Bootstrap container build will include the available blueprint and load them into DCAE-inventory during deployment. Once the blueprints are available in inventory, the deployment can be triggered via Robot suite, CLAMP or DCAE-Dashboard.
ConfigBindingService Integration (Code enhancement required)
All configuration (identified in component spec - parameters) itself are stored under CONSUL when blueprint gets executed part of component deployment. Some configuration such as topics are dynamic and may not be known for component owner to include in the docker image. Hence an important requirement for all onboarding services is to invoke the configbindingservice api during docker init script process to fetch the required application config.
API information - https://onap.readthedocs.io/en/beijing/submodules/dcaegen2.git/docs/sections/apis/configbinding.html
For python - there are libraries available DCAE has SDK/libraries which can be used to invoke this api. For java - sample code and configuration returned can be found here MicroServices Onboarding in ONAP#CodesnippettofetchconfigurationfromConfigbindingservicefor service components for easy integration.
However if library is not suite, then application can consume the ConfigBindingService API directly
Note: Using SDC libraries is recommended as any fixes or enhancement will only require version bump
Notification mechanism (Code enhancement required)
Note: If MS has ability to periodically poll CBS api's and check for updates - support for notification mechanism is optional.
When there are configuration changes (triggered via policy/clamp), the platform will fetch the configuration and store them in consul. The platform will also notify the services indicating there is new configuration (slide below indicates the flow involved)
...
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).
...
License 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% 60% 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
...
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.
...
All DCAE components release specific documentation are maintained as source under https://gerrit.onap.org/r/gitweb?p=dcaegen2.git;a=tree;f=docs;h=e9ccbe4509762968a5028afb8dc55be3236beb6d;hb=refs/heads/master repository. This dcaegen2 repository. his repo has documentation build setup and generated RTD can be found here - https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/index.htmlunder ONAP-RTD
Service component related RST can be added under separate directory created here - https://gerrit.onap.org/r/gitweb?p=dcaegen2.git;a=tree;f=docs/sections/services;h=06c74325e0a604772363faf2a7faecaf94a839ee;hb=refs/heads/masterunder dcaegen2 repository. Post merge/build - corresponding RTD will be located here - https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/services/serviceindex.htmlunder DCAE-Service component page of ONAP-RTD
See Resource at the bottom for more information on RTD.
...
- Common Q&A
- List of Features/JIRA's deferred for next release
- Complaint with ONAP Logging guidelines/CBS integration?
- Can multiple instance be run in-parallel (for scaling)? Any external dependency for persistence?
- Common Q&A
Deployment Integration
...
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.
DCAE JIRA - https://jira.onap.org/secure/RapidBoard.jspa?rapidView=49&view=planning.nodetail
...