DCAE platform being microservice centric, the services 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 under DCAE project.
For community members looking to contribute new service under ONAP DCAE project, below general pre-requisites should be met
- Review new service proposal with architecture team and project team.
- Identify usecase this service will be targeted under (optional).
- 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 sprints to target
- Push seed Code into gerrit (if available)
- Build enhance functional component (mS)
- Setup Jenkins job (under ci-management repo) for building artifacts/docker images.
- CLM/coverty scan and address all CRITICAL/HIGH License/security issues identified ()
- Code Coverage of 50% or more (Important and gating item if component doesn't meet required target)
- S3P (all scaling/resiliency/security/maintainability) goals should meet at the minimum level defined for DCAE project.
- Logging compliance (https://wiki.onap.org/pages/viewpage.action?pageId=28378955)
DCAE Platform Integration
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 and validate using dcae_cli (Design support)
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.
SDC Integration (Design support)
This has to be coordinated with SDC team esp if components has dynamic policy and required CLAMP/Policy integration.
Blueprint creation/test (Test)
If the component is onboarded via SDC, the blueprints can be generated by TOSCAlab tools contained with DCAE-DS in SDC. Alternatively the components developer can hand-craft the blueprints and test. The blueprint created manually if required to included part of DCAE static deployment, then blueprint itself should be templatized and added into this repo - and deployment script (bootstrap) modified to include the new bp.
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.
Notification mechanism (Code enhancement required)
Support for notification mechanism integration is required within MS container/package. The component spec owner will declare in the spec the script that platform should invoke when a configuration change is received (eg. from Policy) This script should be contained within the MS container/package and have necessary logic to invoke CBS API and cascade the information for application processing.
S3P Support (Code enhancement required)
The component is stateful, should persist its state on external store (eg. pg, redis) to allow flexibility of scaling and resiliency. This should be considered part of component design. If the component fails to meet S3P goals, it will not be release candidate.
Deployment Integration
Once the components meet all above criteria, the component should 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)