Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 31 Next »


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.

Pre-requisites for Integration

For community members looking to contribute new service under ONAP DCAE project, below steps outline general steps to be followed by the service owners.

    • 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
    • Build/enhance functional component (mS)
    • Setup Jenkins job (under ci-management repo) for building artifacts/docker images.
    • 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

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

  • DCAE Platform Integration
  • Documentation
  • Demo
  • Deployment integration.

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)

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 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/Policy)

SDC 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 DCAE.

Blueprint creation/test (Test)

If the component are onboarded via SDC flow, the blueprints 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.

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 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)

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)


To support this interface, the service component should include a script within the container and specify that in component spec

Component spec

"auxilary": {
    "policy": {
        "trigger_type": "docker",
        "script_path": "/opt/app/reconfigure.sh"
    }
}

The corresponding blueprint should include following

      docker_config:
        policy:
          script_path: /opt/app/mean/reconfigure.sh
          trigger_type: docker


This script must have necessary logic to invoke CBS API and cascade the information for application processing. For components not expecting dynamic changes, this step is optional.

S3P Support (Code enhancement required)

S3P (all scaling/resiliency/security/maintainability) goals should meet at the minimum level defined for DCAE project for the targeted release 

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).

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. 

README file

         Each of service component repository must include a README instruction on how the repo should cloned, build locally and executed.

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 repo has documentation build setup and generated RTD can be found here - https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/index.html

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/master. Post merge/build - corresponding RTD will be located here - https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/services/serviceindex.html

See Resource at the bottom for more information on RTD.

Demo

To be able to certify the component for release, the MS owner should present demo to project team (and integration team) using onap Jenkins build images/container and manual deployment via blueprint under DCAE platform. This demo should be ideally completed before M4 deadline to meet release timeline.


Deployment Integration

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).



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







  • No labels