DCAE R6 PMSH MicroService

Overview

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

Architecture Diagram

Artifacts

PMSH blueprint	PMSH image: 1.0.2

PMSH blueprint	PMSH image: 1.0.2

Deployment Prerequisite/dependencies

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

Due to a bug (DCAEGEN2-2136). 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-ui --name=x-consul-server-ui --type=NodePort

2. Insert the monitoring policy into CONSUL

PUT policy into CONSUL

curl -X PUT \
  http://<k8s-node-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"
                        }
                    ]
                }
            }
        ]
    }
}'

Starting in Frankfurt, all DCAE service blueprints are bootstrapped, meaning they are all available in the inventory by default and do not need to be onboarded manually. Deployment of PMSH can be done using Dashboard UI/Cloudify UI or via CLI. Below steps are based on CLI using the deployment handler.

1. Get the typeId of PMSH using the inventory API

Get serviceTypeId from DCAE inventory

curl https://<k8s-node-ip>:<inventory-port>/dcae-service-types

The PMSH typeID can then be taken from the response

Inventory response

2. Create a deployment using the deployment handler API

Create PMSH deployment

To un-deploy

Create PMSH deployment

Initial Validation

After deployment, verify if PMSH pod is running correctly

Verify Heartbeat is running

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

If PMSH is working correctly we should see an event published to message router

Response from MR

This can also be verified by checking the logs to verify PMSH can connect to A&AI and DMaaP

Verify PMSH logs

Functional tests

Given that the steps above were used to configure the PMSH monitoring policy with administrativeState = LOCKED. The subscription has not yet been "activated" on the network function.

Activate an inactive subscription

If the subscription is in a LOCKED state (administrativeState=LOCKED) we can reconfigure PMSH to activate the subscription:

Activate Subscription

We should then be able to see a CREATE event sent to message router:

Get from MR

If PMSH is working correctly we should see a CREATE event sent to message router:

Response from MR

Deactivate an active subscription

If the subscription is in an UNLOCKED state (administrativeState=UNLOCKED) we can reconfigure PMSH to deactivate the subscription:

Deactivate Subscription

We should then be able to see a DELETE event sent to message router:

Get from MR

If PMSH is working correctly we should see a DELETE event sent to message router:

Response from MR

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 the configuration can be triggered either from Policy (or CLAMP) or made directly in Consul.

Locate the service name by executing into PMSH Service pod and getting env HOSTNAME value

ServiceName

Change the configuration for Service in KV-store through UI

Consul URL

Consul Snapshot <>