A Rust reimplementation of Oparaca — an Object-as-a-Service platform with separate control and data planes. Control plane manages class/function deployments via Kubernetes; data plane handles invocations, routing, and stateful object storage.
-
Rust toolchain (https://www.rust-lang.org/tools/install)
-
protobuf-compiler,libssl-dev -
Container runtime (Docker/Podman)
-
kubectl, kind, just (for k8s deployment)
-
Control Plane: Package Manager (PM) + Class Runtime Manager (CRM). PM exposes REST API for package/deployment CRUD; talks to CRM(s) via gRPC. CRM is a Kubernetes controller managing
ClassRuntimeCRDs and applying function + ODGM resources. -
Data Plane: Gateway (REST/gRPC ingress), Router (Zenoh messaging), ODGM (stateful object grid), and function runtimes (user code).
graph TB
subgraph CP["Control Plane"]
PM["📦 PM<br/>Package Manager<br/>REST API"]
CRM["⚙️ CRM<br/>Class Runtime Manager<br/>K8s Controller"]
end
subgraph DP["Data Plane"]
GW["🚪 Gateway<br/>REST/gRPC Ingress"]
RT["🔀 Router<br/>Zenoh Messaging"]
ODGM["🗄️ ODGM<br/>Object Data Grid"]
FN["🔧 Function<br/>Runtimes"]
end
subgraph K8S["Kubernetes"]
CRD["ClassRuntime CRD"]
RES["Deployments<br/>Services"]
end
Client["👤 Client"] -->|REST| PM
Client -->|REST/gRPC| GW
PM -->|gRPC| CRM
CRM <-->|Server-Side Apply| K8S
GW --> RT
RT -->|Zenoh| ODGM
RT -->|Zenoh| FN
FN -.->|Discover| ODGM
classDef cp fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef dp fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef k8s fill:#fff3e0,stroke:#f57c00,stroke-width:2px
class PM,CRM cp
class GW,RT,ODGM,FN dp
class CRD,RES k8s
| Component | Location | Role |
|---|---|---|
PM |
|
Package registry, multi-cluster orchestration |
CRM |
|
Kubernetes controller, ClassRuntime CRD, NFR enforcement |
ODGM |
|
Object Data Grid with Raft consensus, separate deployment per class |
Gateway |
|
Stateless ingress, REST/gRPC → Zenoh translation |
Router |
|
Zenoh-based pub/sub and RPC routing |
Commons |
|
Shared libs: models, gRPC protos, Zenoh config, storage abstractions |
String-based object identifiers and string entry keys provide human-readable addressing and richer per-entry semantics alongside existing numeric IDs.
Key points:
-
Enablement: GA and always on. No env flags required. Configure max length via
ODGM_MAX_STRING_ID_LEN(default 160). -
Normalization: Server lowercases all provided
object_id_str; allowed charset:[a-z0-9._:-]; max length configurable viaODGM_MAX_STRING_ID_LEN(default 160). -
Semantics:
-
Numeric Set = upsert (create or replace)
-
String Set = create-only (duplicate returns AlreadyExists)
-
Merge preserves existing entries and adds/updates provided ones
-
-
Entries:
-
Numeric entry keys remain
u32→ValData -
String entry keys stored in parallel map (
entries_str) with identical value type
-
-
Events / Triggers: String keys participate in create / update / delete trigger fanout just like numeric keys.
-
Capabilities: Query via
oprc-cli capabilitiesfor runtime-advertised support. -
CLI Usage Examples:
-
Create string-id object:
oprc-cli object setstr --cls-id users 0 --object-id-str user-42 -s name=alice -s role=admin -
Get single string field:
oprc-cli object getstr --cls-id users 0 --object-id-str user-42 --key-str name -
Numeric coexistence: Both numeric and string objects may exist in same collection and partition.
-
-
Rollback: Disable flags; existing string objects remain addressable internally but new creates will return UNIMPLEMENTED.
Metrics:
-
odgm_object_set_total{variant}andodgm_get_total{variant}differentiate numeric vs string -
odgm_entry_mutations_total{key_variant}increments by key type (numeric|string) -
Gateway attempts / rejections counters:
gateway_string_id_attempt_total,gateway_string_id_rejected_total
Planned:
-
Adoption tracking and default flip to string IDs once usage threshold reached.
-
External: REST (PM, Gateway) and gRPC (PM ↔ CRM, Gateway)
-
Internal: Zenoh pub/sub +
oprc-zrpc(data plane) -
Kubernetes: kube-rs with server-side apply (CRM)
-
Deploy: Client → PM (REST) → CRM (gRPC) → upsert ClassRuntime CRD → reconcile → apply function + ODGM resources
-
Invoke: Client → Gateway (REST/gRPC) → Router (Zenoh) → Function runtime or ODGM
-
Status: Client → PM → CRM → read ClassRuntime conditions
-
Delete: Client → PM → CRM → mark CRD for deletion → cleanup resources
# All tests
cargo test --workspace
# Control plane tests
just -f control-plane/justfile all-it
# Specific service
cargo test -p oprc-crm
cargo test -p oprc-pm
cargo test -p oprc-odgmServices use env-first config via envconfig. Common patterns:
-
Logging:
RUST_LOG=debug,openraft=info,zenoh=info -
Zenoh:
OPRC_ZENOH_PEERS,OPRC_ZENOH_PORT,OPRC_ZENOH_MODE -
CRM:
HTTP_PORT,GRPC_PORT,OPRC_CRM_FEATURES_* -
PM:
SERVER_PORT,CRM_DEFAULT_URL,CRM_CLUSTERS_JSON -
ODGM:
ODGM_HTTP_PORT,ODGM_NODE_ID,ODGM_COLLECTION
See component READMEs for details.
commons/ # Shared libraries
├── oprc-grpc/ # Protobuf definitions & clients
├── oprc-models/ # Domain models
├── oprc-zenoh/ # Zenoh config helpers
├── oprc-dp-storage/ # Data plane storage (memory, redb, fjall, rocksdb)
└── oprc-cp-storage/ # Control plane storage (memory, etcd)
control-plane/
├── oprc-pm/ # Package Manager (REST API)
└── oprc-crm/ # Class Runtime Manager (K8s controller)
data-plane/
├── oprc-gateway/ # REST/gRPC ingress
├── oprc-router/ # Zenoh routing
├── oprc-odgm/ # Object Data Grid Manager
└── oprc-dev/ # Development utilities
tools/
└── oprc-cli/ # CLI tool for OaaS operations-
Original Java implementation: https://github.com/hpcclab/OaaS