UNDER CONSTRUCTION

Introduction

Tutorials on how to use SDNC and the various nodes in the service logic interpreter would seem to be useful to the community.

The vFW demo use case in ONAP requires APPC to have a Netconf Mount to the traffic generator. That mount is created by a step in the robot framework but is actually an interesting way to demonstrate capabilities in SDNC  since the data needed to create the netconf mount point all exists in SDNC. This also demonstrates the type of changes that can be done outside of an SDNC release with just Directed Graph changes.

This tutorial starts with a running ONAP platform configuration and would enhance the existing vFW use case. Instructions and background on the ONAP installation, use case, and interaction are at https://wiki.onap.org/display/DW/Installing+and+Running+the+ONAP+Demos. 

The tutorial will cover a variety of topics as we create and implement a modified directed graph.

Specifically this tutorial will demonstrate how to modify the VNF Topology directed graphs to manage (create, delete) the netconf mount point between APPC and the vTrafficGenerator of the vFW VNF.

The steps will demonstrate activities on the DGBuilder as well as how to use both the FileRecorder node and the RestApiCallNode in the directed graph. None of the steps in the tutorial require a rebuild of SDNC or APPC.

Steps to remove the netconf mount created in the robot test framework are not shown but we may work with the robot framework team to show those as well as a later update.

Loading and Editing Directed Graphs

The first step is to import copies of the two directed graphs that we will want to modify into two tabs in dgbuilder. 

The vnf-topology-operation API/Directed Graph uses the svc-action parameter ( <switch test="`$vnf-topology-operation-input.sdnc-request-header.svc-action`"> ) to run either the activate or delete directed graph (a production version might want to look at the other svc-actions as well).

We need the two directed graphs; vnf-topology-activate and vnf-topology-delete to handle the two events that should affect the netconf mount on APPC (create after instantiating a VNF and delete after removing a VNF)

The graphs are in the SDNC repository under <ONAP_SRC>/sdnc/oam/platform-logic/vnfapi/src/main/json.

  What you need to do is access the DGBuilder container, select a tab or hit "+" to create a new tab , copy the json string of the DG to your clipboard and then use the menu to import the json string from the clipboard.

Access the DGBuilder on port 3000 on the SDNC VM (IP address will vary for your environment since you will be coming in on the public side of the controller not the private Net 10 address)

Change the version to 1.0.0-demo or something to distinguish it from the current active DG.

You also may need to change the execute node references for the AnAI update to refer to org.openecomp.sndc.sli.aai.AAIService instead of the com.att.sdnctl package.

Remember to hit the big red SAVE button in the upper left corner.

Now lets add a FileRecorder node. Move the nodes below the update AnAI node and paste in a Record node. (After testing you should move this node to the Block we are creating below for the base_vfw case so that you only record if it a vFW but its a handy debugging to have a file record at the start of our new steps)

The easiest method to copy one from an existing DG like the vfn-topology-operation

Change the name of the file to "sdnc_appc_netconf.log" so that it is in a separate file from svclogic.log and karaf.log.

Delete attributes we dont care about and renumber so the fields are in order.

<record plugin="org.openecomp.sdnc.sli.recording.FileRecorder">
<parameter name="file" value="/opt/opendaylight/current/data/log/sdnc_appc_netconf.log"/>
<parameter name="field1" value="__TIMESTAMP__"/>
<parameter name="field2" value="`$vnf-topology-operation-input.sdnc-request-header.svc-action`"/>
<parameter name="field3" value="`$vnf-topology-operation-input.vnf-request-information.vnf-name`"/>
<parameter name="field4" value="`$vnf-topology-operation-input.vnf-request-information.vnf-type`"/>
<parameter name="field5" value="`$vnf-topology-operation-input.vnf-request-information.vnf-id`"/>
<parameter name="field6" value="`$vnf-topology-operation-input.vnf-request-information.generic-vnf-name`"/>
<parameter name="field7" value="`$vnf-topology-operation-input.vnf-request-information.generic-vnf-type`"/>
<parameter name="field8" value="`$vnf-topology-operation-input.vnf-request-information.generic-vnf-id`"/>
<parameter name="field9" value="`$preload-data.vnf-topology-information.vnf-topology-identifier.vnf-name`"/>
<parameter name="field10" value="`$preload-data.vnf-topology-information.vnf-topology-identifier.vnf-type`"/>

After the Record node add a Switch node so that we can filter on vFW VNF's only. 

We will use the substr operator to pull out the 8 characters we care about in the vnf-type to detect when its a vfw.

There are probably better methods but this was easy to put in for our use case.

<switch test='`substr($preload-data.vnf-topology-information.vnf-topology-identifier.vnf-type,22,30)`'>
<!-- Aa27262bF2d040799b5c..base_vfw..module-0 →

Next add outcome node with value="base_vfw" and link it to the switch node.

Next add a block node.

We are going to add some logic to find the vpg hostname and ip address from the preload-data , a set node so that we can set some properties and then the restapicall node..

FIND VPG Data

The first node in the block is a for loop that starts at 0 and ends with the length of the vnf-parameters array in the preload data.

<for index='k' start='0' end="`$preload-data.vnf-topology-information.vnf-parameters_length`" >

we then use another block node so that we can switch on the vnf-parameter-name of interest and pull out the vpg_hostname and vpg_ipaddress.

Pay special attention to the back ticking to refer to context memory variables.

SWITCH NODE:

<switch test="`$preload-data.vnf-topology-information.vnf-parameters[$k].vnf-parameter-name == 'vpg_name_0'`">

OUTCOME:

<outcome value='true'>

SET NODE

<set>
<parameter name='prop.vpg_hostname' value='`$preload-data.vnf-topology-information.vnf-parameters[$k].vnf-parameter-value`' />

SWITCH NODE:

<switch test="`$preload-data.vnf-topology-information.vnf-parameters[$k].vnf-parameter-name == 'vpg_private_ip_1'`">

OUTCOME:

<outcome value='true'>

SET NODE

<set>
<parameter name='prop.vpg_ipaddress' value='`$preload-data.vnf-topology-information.vnf-parameters[$k].vnf-parameter-value`' />

Now that we have the traffic generator data we can move on to the rest of the netconf call

SET NODE

The set node will set the parameters needed for the RestAPICallNode.

In a real example you would put this data into the properties file that is read by SDNC or put it into the mysql database but I wanted to demonstrate the set node as an expediant way to do things.

Not that you should replace the <APPC_RESTAPI_PASSWORD> with the correct string.

<set>
<parameter name='prop.appcRestApi.url' value='http://appc.api.simpledemo.openecomp.org:8282' />
<!-- 8181 when doing localhost -->
<parameter name="prop.restapi.templateDir" value="/opt/openecomp/sdnc/data"/>
<parameter name="prop.appcRestApi.sdncOdl.user" value="admin"/>
<parameter name="prop.appcRestApi.sdncOdl.password" value="<APPC_RESTAPI_PASSWORD>"/>

Next we add the Execute node to actually make the REST API Call to the block. Notice that it references the data from set node and template (netconf-mount-template.xml).

We will have to put the template in the directory specified in the prop.restpi.templateDir (/opt/openecom/sdnc/data)  on the SDNC container.

The name of the node is the variable we set above $prop.vpg_hostname".

The method is a "PUT" for the creation of the netconf-mount.

<execute plugin='org.openecomp.sdnc.restapicall.RestapiCallNode' method='sendRequest' >
 <parameter name="templateFileName" value="`$prop.restapi.templateDir + '/netconf-mount-template.xml'`"/>
 <parameter name="restapiUrl" value="`$prop.appcRestApi.url+'/restconf/config/network-topology:network-topology/topology/topology-netconf/node/'+$prop.vpg_hostname`"/>
 <parameter name="restapiUser" value="`$prop.appcRestApi.sdncOdl.user`"/>
 <parameter name="restapiPassword" value="`$prop.appcRestApi.sdncOdl.password`"/>
 <parameter name="format" value="xml" />
 <parameter name="httpMethod" value="put" />
 <parameter name="responsePrefix" value="restapi-result" />

Link the "for" , "record" and "switch" nodes into the block node.

SAVE the DG 

There is a full DG below and in gerrit in case you want to compare it to yours by importing it to another tab in dgbuilder.

For testing using the SLI:ExecutGraph function I would unhook  the AnAI update node from the DG (select and delete the connection between the block and the AnAI node since we will be testing before we have updated AnAI with the VNF data). You can see in the graphic below that the node is in the DG data but not connected to the tree so it won't get executed. We will re-connect the AnAI node to the block after we do the SLI:ExecuteGraph test.

Upload the DG and Activate it.

Installing the REST API payload XML Template

Here are the steps to put the xml template on the sdnc controller docker container. Remember this will get removed if you re-install the docker container.

log into the container with "docker exec -it sdnc_controller_container bash"

cd /opt/openecomp/sdnc/data

and create the file netconf-mount-template.xml with the xml below (everything from <node> to </node> inclusive).

Note that the hostname (prop.vpg_hostname) and IP address (prop.vpg_ipaddress) of the vTrafficGenerator comes from the vnf preload data found during the DG processing.

The rest api call node uses ${variable_name} to indicate a variable from context memory that should be replaced in the template.

<node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
 <node-id>${prop.vpg_hostname}</node-id>
 <host xmlns="urn:opendaylight:netconf-node-topology">${prop.vpg_ipaddress}</host>
 <port xmlns="urn:opendaylight:netconf-node-topology">2883</port>
 <username xmlns="urn:opendaylight:netconf-node-topology">admin</username>
 <password xmlns="urn:opendaylight:netconf-node-topology">admin</password>
 <tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only>
 <!-- non-mandatory fields with default values, you can safely remove these if you do not wish to override any of these values-->
 <reconnect-on-changed-schema xmlns="urn:opendaylight:netconf-node-topology">false</reconnect-on-changed-schema>
 <connection-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">20000</connection-timeout-millis>
 <max-connection-attempts xmlns="urn:opendaylight:netconf-node-topology">0</max-connection-attempts>
 <between-attempts-timeout-millis xmlns="urn:opendaylight:netconf-node-topology">2000</between-attempts-timeout-millis>
 <sleep-factor xmlns="urn:opendaylight:netconf-node-topology">1.5</sleep-factor>
 <!-- keepalive-delay set to 0 turns off keepalives-->
 <keepalive-delay xmlns="urn:opendaylight:netconf-node-topology">120</keepalive-delay>
</node>

Testing the directed graph

Access the sdnc controller container and turn on DEBUG for org.openecomp.sdnc

opendaylight-user@root>log:get all
Logger | Level
--------------
ROOT | INFO
opendaylight-user@root>log:set DEBUG org.openecomp.sdnc
opendaylight-user@root>log:get all
Logger | Level
--------------------------
ROOT | INFO
org.openecomp.sdnc | DEBUG
opendaylight-user@root>logout

Access the apidoc/explorer/index.html on port 8282 of the SDNC Controller 

http://<SDNC_IP>:8282/apidoc/explorer/index.html

Under the SLI-API section we want the execute-graph RPC 

Open the execute-graph section and use the following input json to test the graph.

This sets up preload data including the two parameters of interest (and the length of the parametere array)

(use the data from the VNF-API GET to find matching valudes for the vnf-type, vnf-id, generic-vnf-id from your current preload data)

{
"input": {
"module-name": "VNF-API",
"rpc-name": "vnf-topology-activate",
"mode": "sync",
"sli-parameter": [
{
"parameter-name": "preload-data.vnf-topology-information.vnf-topology-identifier.vnf-type",
"string-value": "E636c6e5747e4eda9dbb..base_vfw..module-0"
},
{
"parameter-name": "preload-data.vnf-topology-information.vnf-parameters_length",
"string-value": "2"
},
{
"parameter-name": "preload-data.vnf-topology-information.vnf-parameters[0].vnf-parameter-name",
"string-value": "vpg_name_0"
},
{
"parameter-name": "preload-data.vnf-topology-information.vnf-parameters[0].vnf-parameter-value",
"string-value": "testname1"
},
{
"parameter-name": "preload-data.vnf-topology-information.vnf-parameters[1].vnf-parameter-name",
"string-value": "vpg_private_ip_1"
},
{
"parameter-name": "preload-data.vnf-topology-information.vnf-parameters[1].vnf-parameter-value",
"string-value": "10.0.0.1"
},
{
"parameter-name": "service-data.oper-status.order-status",
"string-value": "PendingCreate"
},
{
"parameter-name": "service-data.vnf-id",
"string-value": "Vfmodule_Ete_Name3d4e75c0-119d-4c8e-a6bf-179a2bb51831"
},
{
"parameter-name": "vnf-topology-operation-input.vnf-request-information.vnf-id",
"string-value": "Vfmodule_Ete_Name3d4e75c0-119d-4c8e-a6bf-179a2bb51831"
},
{
"parameter-name": "vnf-topology-operation-input.vnf-request-information.vnf-type",
"string-value": "E636c6e5747e4eda9dbb..base_vfw..module-0"
},
{
"parameter-name": "vnf-topology-operation-input.vnf-request-information.generic-vnf-id",
"string-value": "Vnf_Ete_Name3d4e75c0-119d-4c8e-a6bf-179a2bb51831"
}
]
}
}

Note that the input sets up both data that would come in on the RPC and data that is already in the controller.

Check to see the if  the netconf mount is defined in the APPC

http://<appc_ip>:8282/apidoc/explorer/index.html

http://<appc_ip>:8282/apidoc/explorer/index.html#!/network-topology(2013-07-12)/GET_network_topology_get_1

Here is an example for testname1 but your hostname and IP address will be different:

{
"node-id": "testname1",
"netconf-node-topology:sleep-factor": 1.5,
"netconf-node-topology:between-attempts-timeout-millis": 2000,
"netconf-node-topology:host": "10.0.0.1",
"netconf-node-topology:reconnect-on-changed-schema": false,
"netconf-node-topology:tcp-only": false,
"netconf-node-topology:keepalive-delay": 120,
"netconf-node-topology:max-connection-attempts": 0,
"netconf-node-topology:password": "admin",
"netconf-node-topology:username": "admin",
"netconf-node-topology:port": 2883,
"netconf-node-topology:connection-timeout-millis": 20000
},

If you go to operational part of the tree you can see the status of the netconf mounts

http://<appc_ip>:8282/restconf/operational/network-topology:network-topology/

The graphic below shows both one connecting (error) and one connected (success) with the yang models pulled over the netconf session. In this case with 127.0.0.1 that is from APPC itself.

If you want to delete the test netconf mount simply use the apidoc explorer or curl/POSTMAN to delete it. In this case for "testname1" this is the url.

DELETE http://<appc_ip>:8282/restconf/config/network-topology:network-topology/topology/topology-netconf/node/testname1/

Now if those test passed then go back to dgbuilder.

Reconnect the AnAI node to the Block.

SAVE , Upload and Activate the DG.

You can run ETE tests from robot framework at this stage and you should see the netconf mount setup by SDNC (robot might try to set it up a second time be we will ignore that ).

Now that you have the Activate you can proceed to do the same with the Delete  Directed Graph.

This uses the DELETE method to the restapicall node and only need the vpg_hostname so it is a little simpler.

The current VFN-TOPOLOGY-DELETE graph assumes the MSO will be deleting the VNF so it doesnt remove the l3 network data that is still attached to the VNF in AnAI in some cases. You may want to tie the block for processing delete into both of the success branches from the order-status=Active switch test by adding a "true" outcome from the order status="Active" and linking that to the existing block node after the "other" outcome from the switch test of "aic-cllii. As shown below. This way the l3 network data would be removed from AnAI by SDNC since it was added by SDNC on the "activate". The VNF will be deleted in a few seconds after the delete runs but its probably something to consider.

The delete node you want to delete the responsePrefix and template parameter since they are not needed and will generate errors if included in an DELETE operation.

<execute plugin='org.openecomp.sdnc.restapicall.RestapiCallNode' method='sendRequest' >
<parameter name="restapiUrl" value="`$prop.appcRestApi.url+'/restconf/config/network-topology:network-topology/topology/topology-netconf/node/'+$prop.vpg_hostname`"/>
<parameter name="restapiUser" value="`$prop.appcRestApi.sdncOdl.user`"/>
<parameter name="restapiPassword" value="`$prop.appcRestApi.sdncOdl.password`"/>
<parameter name="format" value="xml" />
<parameter name="httpMethod" value="delete" />

The tutorial data will be in gerrit under the demo repository (demo/tutorials/CreateAppcNetconfMount)

Here is a string version for quick reference.