...
- 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 (Required for passing release candidate)
- Code Coverage of 50% or more (Required for passing release candidate)
- S3P (all scaling/resiliency/security/maintainability) goals should meet at the minimum level defined for DCAE project for the targeted release (Required for passing release candidate)
- Logging compliance (https://wiki.onap.org/pages/viewpage.action?pageId=28378955) (Required for passing release candidate)
...
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 around this can be found 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 )
...
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 DCAE.
Blueprint creation/test (Test)
If the component is are onboarded via SDC flow, the blueprints can will 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 - https://gerrit.onap.org/r/#/admin/projects/dcaegen2/platform/blueprints. The blueprint can tested using "cfy" commands (Ms Deployment through Cloudify CLI) pointed to correct DCAE cloudify server.
...
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 which can be used to invoke this api. For java - sample code and configuration returned can be found here MicroServices Onboarding
Notification mechanism (Code enhancement required)
...
If the component is stateful, it should persist its state on external store (eg. pg, redis) to allow flexibility of scaling support for scaling and resiliency. This should be considered part of component designimportant design criteria for the component. If the component fails to meet S3P goals, it will not be release candidate.
...