Container Development Kit (CDK)

The Container Development Kit (CDK) is a set of commands within the BubbleRAN CLI that allow you to take an xApp you have already developed and tested (e.g., one of the xApps from the xApp Training labs) and turn it into a container image and package it into a CompositionModel that can be deployed and managed declaratively through the Network CRD.

In short, the CDK is the bridges the development of an xApp (running it by hand on bare-metal against a RIC, as in xApp Training) to the managed deployment of it (running it as a managed Element inside the cluster, alongside the RAN and the Near-RT RIC).

Why use it

During xApp developing you compile an xApp and run it directly on the bare-metal host (e.g., in the control-plane node), pointing it at a Near-RT RIC IP (requiring to update the xApp configuration every time the network is re-deployed). That is fine for development, but it is not ideal for benchamrking an xApp and evaluating its performance for a given use-case:

• The binary/scripts and their dependencies are not packaged or versioned
• Nothing restarts the xApp if it dies, and it is not part of the network's lifecycle
• It cannot be deployed on a different cluster with a single manifest

The CDK solves this by packaging the xApp into an image and emitting a CompositionModel (the same kind of packaging used for all elements within MX-PDK) so your xApp becomes just another Element in a Network.

How it works

The CDK takes you from xApp code to a running, RIC-connected Element in three steps:

1. Build & push the image — brc cdk image build onboards your xApp on the CDK base image. brc cdk image push uploads it to the cluster-local registry (zot).
2. Install the model — brc cdk model install packages a Helm chart, pushes it to zot, and creates the CompositionModel in the cluster.
3. Deploy via the Network — reference the model from a Network's edge: section; Athena deploys your xApp as an Element wired to the Near-RT RIC.

The cluster-local registry

On a BubbleRAN MX-PDK cluster the CDK does not push to BubbleRAN's public registry. The platform runs a private OCI registry (zot) reachable in-cluster at registry.<cluster>.local:5000. Both your xApp image and the CompositionModel chart live there:

Artifact	Reference
xApp image	registry.<cluster>.local:5000/telco-fabric/<org>/xapps:latest
CompositionModel chart	oci://registry.<cluster>.local:5000/telco-fabric/models/<org>

<org> is your cluster/customer name (taken from the current kubeconfig context), and the credentials are read automatically from the bubbleran-hub secret created by brc login. You do not need to log in to anything by hand.

Where to run the CDK

It is strongly recommended to run brc cdk on the control-plane node of your cluster (e.g. over SSH).

What gets discovered and onboarded by the CDK

An xApp's entry point is simply the file you run to start the xApp: the Python script you would launch with python3 my-xapp.py, or the C source that compiles into the xApp executable. It is the file that initialises the SDK (xapp_sdk.init(...)) and holds the xApp's main loop. In xApp Training, lab5.py and lab5.c are entry points, i.e. they are exactly what you execute to run the xApp.

brc cdk runs from your xapp_sdk directory, scans it for these entry points, and turns each one into a "deployment-mode" of the generated CompositionModel, i.e., one xApp file becomes one selectable xApp you can deploy in a Network. It detects:

• Python entry points — top-level .py files under src/dev/python3/ that call xapp_sdk.init(...). The mode is named after the file (ran-slicing.py → mode ran-slicing).
• C entry points — the targets listed in the LIST_XAPP variable of src/dev/c/CMakeLists.txt (their compiled binaries must already exist under build/src/dev/c/).

Around each entry point it also bundles whatever it needs to run: auto-detected third-party pip packages (from your imports), shared libraries from lib/, and model/data files (.keras, .onnx, .pkl, .csv, …).

Name your entry-point file with hyphens

The deployment-mode is named after the entry-point file with _ replaced by -, and at runtime the manager launches <mode>.py. So ran-slicing.py gives the mode ran-slicing and runs correctly, whereas ran_slicing.py also becomes the mode ran-slicing but then no ran-slicing.py file exists to run. Use hyphens (-), not underscores (_), in entry-point file names.

CDK command cheatsheet

Command	What it does
brc cdk image build	Build a derived xApp image on the CDK base image (--cuda for GPU/AI base).
brc cdk image push	Push the image to the cluster-local registry as telco-fabric/<org>/xapps:latest.
brc cdk image run <image>	Run the image transiently (--rm) to check it starts and finds its dependencies.
brc cdk image shell <image>	Open an interactive shell inside the image; changes are discarded on exit.
brc cdk image patch <image>	Open an interactive shell, then commit whatever you installed/changed into a new image on exit (--target to name it, --push to push).
brc cdk model build	Render the CompositionModel (and its base ConfigMap) to YAML — inspect without deploying.
brc cdk model install	Package the chart, push it to zot, and create/upgrade the CompositionModel in the cluster.
brc cdk model patch	Re-roll the installed model with the latest pushed image (alias of install after an image push).

The CompositionModel the CDK produces contains one deployment-mode per xApp, each with the xapp role, the e42ap port (36422/sctp) used to reach the Near-RT RIC, and an Athena manager sidecar that renders the xApp's runtime config and connects it to the RIC declared in the same Network.

CDK training labs

The two labs that follow continue directly from xApp Training — Lab 5 (KPM+RC xApp for RAN Slicing):

1. Lab 1 — Packaging an xApp into a CompositionModel: take the RAN-slicing xApp you ran on bare-metal and turn it into an image + a CompositionModel published to the cluster-local registry.
2. Lab 2 — Deploying your xApp through the Network CRD: add that CompositionModel to a Network so Athena runs your xApp as a managed Element, wired to the RIC — the productionized version of Lab 5.