Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

    • 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 .(this could be documented in wiki to start, but swagger spec required by M2)
    • 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

...

New DCAE Microservice chart contribution should go under https://git.onap.org/oom/tree/kubernetes/dcaegen2-services; all DCAE component charts should leverage oom/kubernetes/dcaegen2-services/common/dcaegen2-services-common templatesRefer to following link - https://docs.onap.org/projects/onap-dcaegen2/en/latest/sections/dcaeservice_helm_template.html for details on the supported features via this template.

     With Kohn release, all DCAE components will be enabled for daily/weekly deployments. This is controlled by override here - https://git.onap.org/oom/tree/kubernetes/onap/resources/overrides/onap-all.yaml. New components being added under ONAP, should update this yaml for enabling automated daily/weekly deployment. 


DCAE SDK Integration

With Jakarta release, Consul and ConfigBindingService interface has been deprecated from DCAE. All Microservice configuration are resolved through files mounted via Configmap created part of dcae-services helm chart deployment. CBS SDK library are available within DCAE which can be used by DCAE Microservices for configuration retrieval. For details on the API - refer CBS SDK Java Library

...