While the Hello World xApp Use Case Flows page of the Getting Started Guide of the O-RAN RIC shows how to deploy xApps, it neither really explains what is going under the hood, nor does it mention how to undeploy an xApp. We will cover both things in this blog post. Furthermore, the creation of policy types and instances is mixed in there. We will keep this for another post.

For understanding how to deploy an xApp, you should know that the RIC manages the lifecycle of apps, i.e., apps are managed by RIC, and not by Kubernetes directly. Now, have a look at the the overview picture. The lifecycle of an xApp is the following:

1. The xApp gets onboarded, i.e., the xAppOnboarder takes a descriptor to generate the actual helm chart, that it then puts into the Helm Chart repo (chartmuseum) running within the xAppManager.
2. The xApp gets deployed, i.e., the xAppManager loads the application using the previously uploaded helm chart, and Kubernetes manages to deploy the application.
3. The xApp gets undeployed, i.e., the xAppManager stops the respective microservice using Kubernetes.

Onboarding

Onboarding means to give the controller information about the application to deploy. This is done through a descriptor. As shown in “Step 1: Prep tasks”, this might be not more than a JSON file with a link to the actual descriptor. Thus, onboard.qp.url looks like this:

{
  "config-file.json_url": "https://gerrit.o-ran-sc.org/r/gitweb?p=ric-app/qp.git;a=blob_plain;f=xapp-descriptor/config.json;hb=HEAD"
}

You can the onboard like so:

$ curl -L -XPOST "http://$(hostname):32080/onboard/api/v1/onboard/download"  -H 'Content-Type: application/json' -d @./onboard.qp.url

There is not much to it, and you are restricted to a predefined descriptor. To see what is actually going on, download the file, replace the link including "" with the file and change config-file.json_url with config-file.json:

{
  "config-file.json": {
    "xapp_name": "qp",
    "version": "0.0.2",
    "containers": [
      {
        "name": "qp",
        "image": {
          "registry": "nexus3.o-ran-sc.org:10002",
          "name": "o-ran-sc/ric-app-qp",
          "tag": "0.0.3"
        }
      }
    ],
    "messaging": {
      "ports": [
        {
          "name": "rmr-data",
          "container": "qp",
          "port": 4560,
          "rxMessages": ["TS_QOE_PRED_REQ"],
          "txMessages": ["TS_QOE_PREDICTION"],
          "policies": [],
          "description": "rmr receive data port for qp"
        },
        {
          "name": "rmr-route",
          "container": "qp",
          "port": 4561,
          "description": "rmr route port for qp"
        }
      ]
    },
    "rmr": {
      "protPort": "tcp:4560",
      "maxSize": 2072,
      "numWorkers": 1,
      "rxMessages": ["TS_QOE_PRED_REQ"],
      "txMessages": ["TS_QOE_PREDICTION"],
      "policies": []
    }
  }
}

What you can see is information about the container image, as well as the way RMR (the RIC-internal messaging library for inter-container communication) is used. To onboard using this descriptor, you would then use the /onboard/api/v1/onboard, i.e. without download.

If everything has worked out, RIC shows it with the Created status message. To see the onboarded xApps, use the /onboard/api/v1/charts endpoint:

$ curl "http://$(hostname):32080/onboard/api/v1/charts"

Deploying

To deploy an app, simply make a REST POST for the corresponding xApp:

$ curl --location -XPOST "http://$(hostname):32080/appmgr/ric/v1/xapps"  -d '{"xappName": "qp"}' -H 'Content-Type: application/json'

The status should be deployed in the server’s response. The xappName to use here is the one from the descriptor.

You should see a new micro-service in the ricxapp namespace:

$ kubectl get pods -nricxapp
NAME                                   READY   STATUS    RESTARTS   AGE
ricxapp-qp-867d9558c-v26mp             1/1     Running   0          93s

To see the logs of the newly created xApp, use the logs command:

$ kubectl logs -nricxapp ricxapp-qp-867d9558c-v26mp

Undeploying

The guide does not tell you how to undeploy an xApp. This can be achieved by using the HTTP DELETE method:

$ curl -X DELETE "http://$(hostname):32080/appmgr/ric/v1/xapps/qp"

It should also disappear from the list of pods.

How to delete a descriptor from the xAppOnboarder?

I did not find a way (yet) to delete descriptors from the onboarder. However, you can just push a new descriptor for a given application, and the old descriptor will be overwritten.