APPC Services Development

Owned by Deven
Last updated: Feb 29, 2024
4 min read

The Application Controller (APPC) has been built on top of the OpenDaylight SDN controller. Let us see how to develop services within this APPC framework, by taking the example of the VM Status Check service, which is integral to anything you do in and with APPC and ONAP.

VM Status Check Service

Purpose:

It can be used to check the status of the VM requested.

 

Description:

The status may be deleted, running, error, ready, paused or suspended, pending or default-unknown state. This functionality piggybacks Openstack’s ability to check status of the VMs.

The terms used for describing the status, are in conformity with the terminology used in the APPC project.

 

Usage:

In the API explorer, go to the vmstatuscheck rpc and use the query below. You should be able to get back the response with the current status of the VM queried.

Clarification: This would be possible only if I commit some more code, so that the vmstatuscheck rpc can be seen in the API explorer. I have this running on my machine.

 

Sample Query:



{ "input": { "common-request-header": { "service-request-id": "1" }, "vnf-resource": { "vm-id": "http://controller:8774/v2/c630e297a3ae486497d63eacec1d7c14/servers/4026899f-c574-4872-aec2-6aee32597ba1" } } }





Note: In the json query, vmid mentioned must be supported by the Openstack provider being used in the appc.properties file being used by the APPC instance. If this doesn’t work, use a vmid in the Openstack to which you have access i.e whose credentials are mentioned in the appc.properties file in the APPC you are using.



Sample Response:

{   "output": {     "common-response-header": {       "completed": "2016-08-01 10:30:37.000435",       "reason": "Success",       "duration": 1465,       "success": true,       "service-request-id": "1"     },     "stat-msg": "running"   } }





DG Modification needed to support this functionality:

Add the following to the APPC topology-operation-all 2.0.0 DG to make sure VM Status check is supported.





<outcome value='vmstatuscheck_action'>                 <execute plugin='com.att.appc.adapter.iaas.ProviderAdapter' method='vmStatuschecker'>                     <parameter name="com.att.appc.provider.name" value="OpenStack" />                     <parameter name="com.att.appc.instance.url" value="`$com.att.appc.vmid`" />                     <parameter name="com.att.appc.identity.url" value="`$com.att.appc.identity.url`" />                     <outcome value='success'>                         <return status='success'></return>                     </outcome>                     <outcome value='Other'>                         <return status='failure'>                             <!-- <parameter name='error-code' value='500' /><parameter name='error-message' value='failed' /> -->                         </return>                     </outcome>                 </execute>             </outcome>



Sample query/response image:

NOTE: The note mainly addresses the following:

Using the vmStatuschecker method in a larger composite task

AND

Integration with existing and future changes in the APPC architecture :

 

The vmStatuschecker method also returns the status of the VM in com.att.statusofvm (which holds the status of the VM), which can be checked in a DG, which calls the vmStatuschecker method. The DG can then call another method after ascertaining say that the VM is running. This can be used in the scenario where a DG calls multiple methods of multiple adapters and tries to achieve a larger composite task like Healthcheck (checking the health of particular VM).

This case assumes that the vmStatuschecker would be called via a separate DG performing the  aforementioned composite task. (instead of modifying APPC topology-operation-all 2.0.0 DG ).

Lets say this new DG is APPC Composite-task_1. This new DG would look something like this-















Fig: The DG for Composite_task_1 talked about above. 

Here,

The Block node executes 4 tasks

-executes vmStatuschecker

-executes some_method1 of some_adapter1

-executes some_method2 of some_adapter2

-calls another graph using the call node.



After executing VM Status check, switch node checks its output.

If its not running, it attempts to restart it by executing calling the restart method.

If it is already running, the block statement then executes the following in order as already explained.

-execute some_method1 of some_adapter1

-execute some_method2 of some_adapter2

-call another graph using the call node. In this case, it calls the DG which accomplishes APPC Composite_task_2 .



This would also be an example of a DG calling another DG, but calling another DG from within a DG could be avoided at the moment.



Furthermore, the APPC Composite-task_1 DG itself could be called via a Composite-Task_1 rpc in the API explorer OR using the dispatcher.

In either case, care would have to be taken to pass all those parameters that all the adapter methods called in the DG expect as input, in the JSON query.

Question: In case of a DG calling another DG, how will parameters needed by the called DG (that which is being called by the first DG) be passed? Will they be passed with the parameters of the calling DG, when it is invoked?

If and when the dispatcher is used, the method would be migrated to be used by the dispatcher in the same way the other RPC’s like Restart, Rebuild etc. would be migrated to be used by the dispatcher.