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

Compare with Current View Page History

« Previous Version 11 Next »

Overview

The PM Subscription Handler (PMSH) is a micro service written in Python, which allows for the definition and unlocking of PM subscriptions on one or more network function (NF) instances.

Architecture Diagram



Artifacts



Deployment Prerequisite/dependencies

  1. The following components must be up and running to successfully deploy PMSH

    1. DCAE Platform
    2. SDC
    3. CLAMP 
    4. POLICY
    5. A&AI (Should have at least 1 PNF registered)

Deployment Steps


In the Frankfurt release, there is a workaround required in order to deploy the PM Subscription Handler. The monitoring policy for the microservice needs to be manually inserted into CONSUL. This requires two steps:


1. The CONSUL service is no longer exposed in the Frankfurt release, this needs to be exposed in order to be accessible outside the k8s cluster.

Expose CONSUL service
kubectl expose svc -n onap consul-server --name=x-consul-server --type=NodePort

2. Insert the monitoring policy into CONSUL

PUT policy into CONSUL
curl -X PUT \
  http://<onap-ip>:<consul-port>/v1/kv/dcae-pmsh:policy \
  -H 'Content-Type: application/json' \
  -d '{
    "subscription": {
        "subscriptionName": "test-subscription",
        "administrativeState": "LOCKED",
        "fileBasedGP": 15,
        "fileLocation": "/pm/pm.xml",
        "nfFilter": {
            "swVersions": [
                "1.0.0"
            ],
            "nfNames": [
                "^pnf.*"
            ]
        },
        "measurementGroups": [{
                "measurementGroup": {
                    "measurementTypes": [{
                            "measurementType": "countera"
                        },
                        {
                            "measurementType": "counterb"
                        }
                    ],
                    "managedObjectDNsBasic": [{
                            "DN": "dna"
                        },
                        {
                            "DN": "dnb"
                        }
                    ]
                }
            },
            {
                "measurementGroup": {
                    "measurementTypes": [{
                            "measurementType": "counterc"
                        },
                        {
                            "measurementType": "counterd"
                        }
                    ],
                    "managedObjectDNsBasic": [{
                            "DN": "dnc"
                        },
                        {
                            "DN": "dnd"
                        }
                    ]
                }
            }
        ]
    }
}'


Deployment of PMSH can then be done using Dashboard UI/Cloudify UI 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-pmsh.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 pmsh -d pmsh -i /k8s-pmsh-inputs.yaml /blueprints/k8s-pmsh.yaml

To un-deploy

  • Uninstall running component and delete deployment

    Uninstall component
    cfy uninstall pmsh
  • Delete blueprint

    Delete blueprint
    cfy blueprints delete pmsh
    

Initial Validation

After deployment, verify if PMSH pod is running correctly

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

dep-dcae-pmsh-6b58cbc7f5-lm92g                                2/2     Running            0          149m


We can curl message router to verify that PMSH has published an event to it's configured topic. By default this is unauthenticated.DCAE_CL_OUTPUT

Get from MR
curl -k https://message-router:3905/events/unauthenticated.DCAE_CL_OUTPUT/1/1


If PMSH is working correctly we should see an activation event

Response from MR
["{\"nfName\":\"pnf500\",\"policyName\":\"pmsh-operational-policy\",\"changeType\":\"CREATE\",\"subscription\":{\"administrativeState\":\"LOCKED\",\"subscriptionName\":\"test-subscription\",\"measurementGroups\":[{\"measurementGroup\":{\"measurementTypes\":[{\"measurementType\":\"countera\"},{\"measurementType\":\"counterb\"}],\"managedObjectDNsBasic\":[{\"DN\":\"dna\"},{\"DN\":\"dnb\"}]}},{\"measurementGroup\":{\"measurementTypes\":[{\"measurementType\":\"counterc\"},{\"measurementType\":\"counterd\"}],\"managedObjectDNsBasic\":[{\"DN\":\"dnc\"},{\"DN\":\"dnd\"}]}}],\"fileBasedGP\":15,\"fileLocation\":\"/pm/pm.xml\"},\"closedLoopControlName\":\"pmsh-control-loop\"}"]



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 pmsh (set in blueprint configuration)


Configuration
 


To simulate the event flow and trigger missing pmsh event, we can simulate a VES event into pmsh subscription topic (using curl).

Generate pmsh CL Onset


Trigger a CL event via curl
 


Logs showing event being processed
 


We can check that a new DCAE_CL_OUTPUT event has been published (make sure you target the correct DMaaP IP address)

Fetch events from DCAE_CL_OUTPUT topic
curl http://10.12.5.8:30227/events/unauthenticated.DCAE_CL_OUTPUT/vv/1


Published event
 


Dynamic Configuration Update

As the pmsh service periodically polls Consul KV using configbindingService api's - the run time configuration of pmsh 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 pmsh Service pod and getting env HOSTNAME value

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

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

Change the configuration for Service in KV-store through UI

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


Consul Snapshot <>

  • No labels