Architecture

External View

View as Markdown

RMS is structured as thin, protocol-specific gateways over an orchestration layer. A gRPC gateway translates requests into calls on the orchestrator, which owns the rack map and the job tracker. Rack implementations create node objects, and node implementations hide the protocol-specific I/O behind a common trait. Nodes are pure async I/O - they have no knowledge of job tracking or scheduling.

The service is built on tokio for async I/O, tonic for gRPC, and trait-based polymorphism for extensibility across node and rack types.

For how these layers fit together internally, see Internal View.

Northbound and southbound connections

RMS has one northbound (incoming client) interface - the RackManager gRPC API - and several southbound (outgoing) interfaces it uses to reach hardware.

RMS northbound and southbound connections

DirectionPeerProtocol(s)Notes
NorthboundgRPC clientsgRPC over mTLS (TLS 1.3, rustls)Single RackManager service; plaintext only in insecure dev mode.
NorthboundPrometheusHTTP(S) /metricsIndependent listener; optional TLS reusing the gRPC server cert.
SouthboundCompute tray & power-shelf BMCRedfish over HTTPSPower, reset, device info, firmware inventory, multipart firmware upload.
SouthboundNVSwitch tray (NVUE/NVOS)NVUE REST over HTTPS, SSH, SFTPSwitch firmware, system images, passwords, certificates, config. SFTP uploads switch OS images.
SouthboundNVSwitch tray (NMX-C)NMX-C gRPC, gNMIScale-up fabric manager state and telemetry-interface control.