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

Version 1 Next »

Overview


Architecture Diagram



Artifacts

Βlueprint (deployment artifact) :

Input file (deployment input)    :

Docker image                            : nexus3.onap.org:10001/onap/<>



Deployment Prerequisite/dependencies



Deployment Steps


Deployment of dl-handler can be done using Dashboard UI or CloudifyUI or via CLI. Below steps are based on CLI.


  • Transfer blueprint component file in DCAE bootstrap POD under /blueprints directory
  • Transfer blueprint component inputs file in DCAE bootstrap POD under / directory
  • Log-in to the DCAE bootstrap POD's main container

  • Validate blueprint

    Validate Blueprint
    cfy blueprints validate /blueprints/k8s-dl-handler.yaml

  • Verify Plugin versions in target Cloudify instance match to blueprint imports

    Verify Plugin version
    cfy plugins list

    If the version of plugin used are different, update the blueprint import to match.

  • Deploy Service

    Upload and deploy blueprint
    cfy install -b dl-handler -d dl-handler -i /k8s-dl-handler-inputs.yaml /blueprints/k8s-dl-handler.yaml

To un-deploy

  • Uninstall running component and delete deployment

    Uninstall component
    cfy uninstall dl-handler

  • Delete blueprint

    Delete blueprint
    cfy blueprints delete dl-handler

Initial Validation

After deployment, verify if dl-handler POD and mongoDB pod are running correctly

Verify Heartbeat is running
root@k8s-rancher:~# kubectl get pods -n onap | egrep "dl-handler"


And then check the logs to see if it can connect to DMaaP, polling for events.

Verify Logs for Dmaap poll

Functional tests

Following default configuration is loaded into dl-handler (set in blueprint configuration)


Configuration


<Add below steps to configure DL-Handler to subscribe and feed into external DL with step-by-step procedure>


Dynamic Configuration Update

As the dl-handler service periodically polls Consul KV using configbindingService api's - the run time configuration of dl-handler service can be updated dynamically without having to redeploy/restart the service. The updates to configuration can be triggered either from Policy (or CLAMP) or made directly in Consul.

Locate the servicename by executing into dl-handler Service pod and getting env HOSTNAME value

ServiceName 
root@k8s-rancher:~# kubectl exec -it -n onap dep-s78f36f2daf0843518f2e25184769eb8b-dcae-dl-handler-servithzx2 /bin/bash
Defaulting container name to s78f36f2daf0843518f2e25184769eb8b-dcae-dl-handler-service.
Use 'kubectl describe pod/dep-s78f36f2daf0843518f2e25184769eb8b-dcae-dl-handler-servithzx2 -n onap' to see all of the containers in this pod.

misshtbt@s78f36f2daf0843518f2e25184769eb8b-dcae-dl-handler-service:~/bin$ env | grep HOSTNAME
HOSTNAME=s78f36f2daf0843518f2e25184769eb8b-dcae-dl-handler-service

Change the configuration for Service in KV-store through UI and verify if updates are picked

Consul URL
http://<k8snodeip>:30270/ui/#/dc1/kv/


Consul Snapshot <>

  • No labels