Extending Racora

This page is for builders: someone bringing another Kubernetes platform, another 5G core or an Intelligence Function to Racora. Operating a Racora network never needs it.

A Distribution Is Extended by Adding Modules

Kubernetes is extended at runtime, with CRDs and operators you install into a running cluster. Racora is not: it has no plugin API. It is extended the way a distribution is, by adding a module to the distribution itself, in the racora repository, behind a contract that the layer above relies on and never looks past. The network layer (the NRCell and Subscriber APIs, the controllers, the CU planes, the Intelligence Plane) is identical whatever modules are selected, and its code never branches on which one is: the selector is a value, the module is data the installer and the chart consume.

Two module families exist today, and they share one shape:

Family	Directory	Selected by	Contract
Platform: the Kubernetes underneath	platforms/<name>/	INSTALL_RACORA_PLATFORM	Platforms, platforms/README.md
Core provider: the 5G core	cores/<name>/	INSTALL_RACORA_CORE (helm: global.core.provider)	How Core Providers Work, The 5G Core, cores/README.md

The Intelligence Plane has an extension point of its own kind, Intelligence Functions inside CU-IP, described on its page.

What Every Module Has

• One directory named after the module. The front door installer resolves it next to itself (from the release package, or the checkout you run from) and refuses a name that is not in its supported list (RACORA_PLATFORMS_SUPPORTED, RACORA_CORES_SUPPORTED).
• values.yaml: facts, nothing else. A platform overlay carries platform facts (CRD ownership, RuntimeClass ownership, placement); a core overlay carries only global.core.*. Neither ever carries image pins, which come from the released chart, nor the other family's facts.
• README.md: the module's row of its contract, in prose. The page about the module on this site is authored from it.
• Conformance, not trust. The installer's static contract and the contract suite exercise every module the same way; a module supplies the suite's hooks, and the suite's assertions are the contract. A core's subscriber hook must prove the core serves the declared subscriber through the core's own read path, not that a row exists in its store.

What differs per family is the mechanism the module provides:

• A platform ships install.sh, sourced by the front door, defining four functions: platform_validate, platform_run, platform_uninstall <scope> and platform_owns_cluster. It decides how the cluster is obtained, how the RAN payload is delivered, how the node contract is implemented on the host, and which uninstall scopes it owns.
• A core provider ships an optional Helm subchart (chart/, named racora-core-<name>, rendering nothing unless selected) and optional host units (host/, one .sh and .service pair per unit, templated on the cluster runtime's service, plus an optional teardown.sh for the host-scope uninstall). It fulfils the seven items of The Core Contract.

Adding One

The repository's contracts carry the step lists and stay authoritative: adding a platform, adding a core. In both cases the work is the directory, its registration in the installer, its hooks in the contract suite, and its page in the matching section of this site (Platforms, The 5G Core). A core that brings an image declares it in versions.yaml: as a CNS-built image resolved at release time, or as an unmodified upstream image the release mirrors.

A module is developed in a checkout: RACORA_PLATFORMS_DIR and RACORA_CORES_DIR point the installer at the directory holding it instead of the release package, and the module then installs like a shipped one. The name still has to be in the installer's supported list, which is why a new module ends up in the repository.

What Is Not an Extension Point

The charts, the controller and the CU planes are the product, identical everywhere; the NRCell and Subscriber APIs are the operator's surface, not a plugin surface. Anything a module needs from them is added to the contract, never as a branch on the module's name.