Service Resource Manager¶

The Service Resource Manager (SRM) carries out every service request of OpenOP. It decides where work runs, keeps the inventory, and drives the infrastructure through the Transformation Function SDK (TF-SDK).

New in this release¶

SRM is rewritten as a FastAPI service backed by PostgreSQL. It takes commands from OEG and FM over the DataBus (NATS), publishes an event for each outcome, and serves an internal HTTP API for reads. TF-SDK 2.0 runs inside SRM, and every zone and backend is reached through a control path declared once in a TF-SDK bootstrap file.

• Capability kinds. workload (Kubernetes, as a Helm chart or a single container), qod_session, traffic_influence and location_context (5G core NEFs). The TF-SDK support matrix lists which backend supports which kind.
• Internal API (/internal). Service specification catalogue, zones, service instances, network capabilities and device location, plus /healthz and /readyz.
• Federation. A deploy or terminate whose target is a partner's zone is handed over to FM on the DataBus. SRM also runs without FM when federation is turned off.
• Containers accept optional cpu_millicores and memory_mb.
• An instance monitor refreshes the state of running instances at a configurable interval.

Breaking changes¶

• The 1.x REST API is removed (/serviceFunction, /deployedServiceFunction, /node, /helm, /sessions and the rest). CAMARA requests enter through OEG.
• PostgreSQL and NATS replace MongoDB and the artefact manager.
• Adapters come from one bootstrap file (BOOTSTRAP_TOPOLOGY_PATH) instead of environment variables. Without it, SRM starts with an empty topology and deploys nothing.
• TF-SDK is renamed. SRM pins openop-tfsdk==2.0.0. Upgrade TF-SDK, SRM and the chart values together.
• deploy_workload is now workload. Errors on the internal API use RFC 7807 problem details.

Upgrade notes¶

Install fresh with oop-platform 2.0.0; nothing is migrated from 1.0.0. Write a TF-SDK bootstrap for your zones and backends and give it to the srm subchart (see how to define zones). Each Kubernetes control path needs an explicit kubeconfig, context and namespace, or in-cluster mode with a namespace.

Known limitations¶

The full list is in the spec's Implementation & Delivery › Known Gaps. The main ones:

• DataBus delivery is not durable: no acknowledgement, redelivery or dead-letter subject.
• Scale and network capability update commands are received and logged, but not handled.
• No reconciliation with the infrastructure and no drift reports. The instance monitor only refreshes states.
• Placement takes the first candidate. Placement constraints and capacity checks are not applied. Keep one network domain per capability kind.
• Reads by id (/service-instances/{id}, /network-capabilities/{id}) are not filtered by tenant.
• One failed target fails the whole deploy, including targets that already run.
• No database migrations. A fresh database gets the current tables at startup.
• No metrics. Logs are the only signal.