Definition

Related Epic: SDNC-887

There are two new services arround SDN-R Mountpoints planned:

• Use DMaaP as ONAP internal communication services

• Create two seperate bundles in ccsdk/feature-sdnr/wt

• Overall architecture: SDNC-888

Mountpoint provider

1. Deliver SDN-R Mountpoint status changes over DMaaP

2. Stories are: SDNC-889 

3. Proposed bundle name: sdnr-wt-mountpoint-state-provider

4. Register listener to MDSAL for mountpoint changes and provide related information

5. Related disussion: model-driven DMaaP Agent

6. Uses ClusteredDataTreeChangeListener for NetconfChangeListener

Mountpoint registrar for VES

1. Manage SDN-R Mountpoints

2. Methods are: Create, Remove

3. Stories are: SDNC-890

4. Proposed bundle name: sdnr-wt-mountpoint-registrar

5. VES message: pnfRegistration

6. New!: Additional VES messages for PoC "Basic Fault Message Flow" and "Basic Configuration Message Flow": (See VES-Notification processing) 

Integration test

1. Story: SDNC-891

Development related

• Location for bundles: ccsdk/feature - sdnr/wt

• Development: Repository: onap-sdnr, branch:odlux-provider

• Test environment with container setup: dmaap + sdnr + sdnrdb

• Sending VES Message in https://git-highstreet-technologies.com/highstreet/sdnr-interfacing-aai-dcae

• Command for registration: pnfRegistration

• Use case: https://lf-onap.atlassian.net/wiki/display/DW/5G+-+Configuration+with+NETCONF

• JSONSchema: https://git.onap.org/dcaegen2/collectors/ves/tree/etc/CommonEventFormat_30.0.1.json

• Version of VES: 7.1 Files Version: 30.0.1

• Simulator VES/Netconf: Availability October

Open:

• Topic name in DMaaP for such messages: unauthenticated.VES_PNFREG_OUTPUT

Configuration files

1. The mountpoint-registrar bundle uses 1 configuration file (it is located in the $ODL_HOME/etc directory by default) - 

   1. mountpoint-registrar.properties - Contains the consumer Java class name and the consumer properties. By default the HTTPNOAUTH transport type is used by the consumer. For other applicable transport types and their corresponding properties, please refer to - Feature configuration requirements. This properties file is auto-generated in its entirety if it does not exist. If certain properties are missing in an already existing file that is present in the $ODL_HOME/etc directory before the bundle starts, the missing properties are included automatically into the existing file. The file contains the following properties - 

Usage

1. Install DMaaP as per instructions in - How to set up a local DMaaP installation in Docker for testing. This is based on Amsterdam. The latest DMaaP repository can be retrieved using information in - Resources and Repositories (Deprecated)#DataMovementasaPlatform

2. Installing and starting DMaaP as per the instructions in (1) above brings up 3 docker containers - dmaap:localadapt , dockercompose_kafka and wurstmeister/zookeeper

3. Install VESCollector. Detailed instructions are at - https://github.com/onap/dcaegen2-collectors-ves. The DMaaP topics that VESCollector manages are present in etc/DmaapConfig.json file. cambria.topic refers to the topics that VESCollector manages. cambria.hosts value should match the IP Address/Hostname of the DMaaP instance.

4. Once we have DMaaP, Kafka, zoopkeeper and VESCollector running, we can send pnfRegistration VES message using the pnfRegister.sh script located at https://git-highstreet-technologies.com/highstreet/sdnr-interfacing-aai-dcae. The "config" file has to be updated with the correct DCAE VES Collector communication end point

5. On executing the pnfRegister.sh script (ex: pnfRegister.sh 1234), a VES message is sent to the VESCollector which processes the VES message and checks for conformance as per the JSON schema and if everything is fine, puts the message in the DMaaP topic

6. Deploy SDN-R and check if the mountpoint-registrar bundle is running correctly by looking for the following messages in the karaf.log - 

   1. DMaaPPNFRegVESMsgConsumer received ResponseCode: 200

   2. DMaaPPNFRegVESMsgConsumer received ResponseMessage:

   3. No data received from fetch. Pausing 5000 ms before retry

7. Once the mountpoint-registrar bundle is running correctly, it starts to consume any VES messages coming on the topic and creates a mountpoint in SDN-R by parsing the information in the VES Message. The created mountpoint can be seen by logging into the ODLUX GUI. 

8. Currently the created mountpoint uses SSH for communicating with the PNF. A TLS based mountpoint implementation is in the works.

pnfRegistration VES Message flow 

Message flow (for registering a mountpoint with TLS protocol)