DSX OS#

Use this section to connect Dynamic Power Software (DPS) to DSX Exchange and operate the DSX Agent integration.

Start with DSX Agent Deployment Guide for deployment prerequisites, authentication, and connection settings.

Integration Architecture#

The diagram shows the DSX Agent power-management integration, its dependencies, and the DPS control and hardware paths. Dashed connections show optional integrations or mounted configuration. In the diagram, MQTT means Message Queuing Telemetry Transport, and TLS means Transport Layer Security.

flowchart TB ISV["Grid applications<br/>Publishers and consumers"] Exchange["DSX Exchange<br/>MQTT broker"] Agent["DSX Agent<br/>Load targets and power state"] DB[("PostgreSQL<br/>Agent queues and DPS state")] Secrets["Kubernetes Secrets<br/>Credentials, CAs, and JWS keys"] Issuer["Optional OAuth2 providers"] DPS["DPS control service<br/>NvGrid and power policies"] Config["Optional Power Steering<br/>Config Service"] Controller["Optional Power Steering<br/>Controller"] Access["DPS hardware access<br/>Server or DPS device agent"] Proxy["Optional Redfish proxy<br/>NVIDIA Infra Controller"] BMC["Node BMCs<br/>Redfish interface"] Hardware["Managed node hardware<br/>CPUs, memory, and GPUs"] ISV -->|"MQTT: signed load targets"| Exchange Exchange -->|"MQTT: signed power state"| ISV Exchange -->|"MQTT/TLS: load targets"| Agent Agent -->|"MQTT/TLS: power state"| Exchange Agent <-->|"Persistent message queues"| DB DPS <-->|"Persistent control state"| DB Agent -->|"NvGrid gRPC/TLS"| DPS DPS -->|"HTTP: ramp events"| Agent Secrets -.->|"Mounted credentials and keys"| Agent Issuer -.->|"Token acquisition"| Agent DPS -.->|"Domains and budgets"| Config Config -.->|"Domain configuration"| Controller DPS -.->|"Controller settings"| Controller Controller <-.->|"Telemetry and GPU limits"| DPS DPS <-->|"Policies and telemetry"| Access Access <-->|"Direct Redfish access"| BMC Access <-.->|"Proxied Redfish"| Proxy Proxy <-.->|"Redfish"| BMC BMC <-->|"Power limits and telemetry"| Hardware

The DSX Agent and the DPS device agent have different roles. The DSX Agent connects NvGrid to Exchange and uses gRPC for load targets, status queries, and webhook registration. Hardware access belongs to the DPS server or its device agents. Ramp-event callbacks travel directly from the control service to the DSX Agent when power-state publication is enabled. A remote device agent initiates its gRPC connection to the control service.

PostgreSQL stores the agent queues and DPS control state. These can use separate databases or database servers. Configure the agent database independently of the DPS database.

Power Steering and the Redfish proxy are optional. Use direct Redfish access or a configured proxy for each hardware path. Power Steering requests GPU limits through DPS, which validates and applies them. Refer to DPS Power Steering Controller for its control loop.

The credential source depends on your deployment. OAuth 2.0 token acquisition is optional; mounted token files and DPS password login are alternatives. The mounted JSON Web Signature (JWS) keys sign or verify message payloads separately from connection authentication.

Integration Responsibilities#

The integration connects three components:

  • DSX Exchange carries MQTT messages between the DSX Agent and external grid applications.

  • DSX Agent validates incoming messages, queues them in PostgreSQL, and translates load targets into DPS NvGrid API calls. It also signs and publishes power-state messages to DSX Exchange.

  • DPS control service owns feed metadata, load-target schedules, and power management. The DSX Agent uses the gRPC API to request changes and read status.

The implemented bridge handles load-target requests and power-state status. Do not assume that every event defined in a DSX schema has a handler in the DSX Agent.

Refer to NvGrid for feed constraints, eligible resource groups, and power restoration. Use Managing NvGrid to inspect feed metadata, schedules, and status directly through DPS.

Load Targets and Status#

A load-target request follows this path:

  1. An external application publishes a load-target message to DSX Exchange.

  2. The DSX Agent validates the message schema and signature, then stores the request for processing.

  3. The DSX Agent calls NvGrid.SetLoadTarget to update the feed schedule.

  4. DPS applies the schedule through its power-management controls. Check status to determine whether the requested target is met.

When power-state publication is enabled, the agent publishes periodic snapshots and updates after processing load targets. These snapshots include feed metadata, scheduled targets, calculated load, and transition status. Calculated load is a DPS value and can differ from measured data center consumption.

With power-state publication enabled, the agent registers its HTTP callback address through NvGrid.RegisterWebhook for the start and end of ramp-up and ramp-down events. DPS sends notifications to that address, and the agent uses them to publish power-state updates. Configure the advertised address for reachability from DPS and include it in the DPS webhook whitelist (dps.nvgrid.webhook.whitelist). The agent callback uses HTTP and does not authenticate its sender. Restrict inbound callback traffic to DPS and ensure your cluster network plugin enforces the ingress NetworkPolicy. Refer to DSX Agent Deployment Guide.

Deployment Boundaries and Verification#

Deploy the DSX Agent with access to DSX Exchange, PostgreSQL, and the DPS gRPC API. Configure MQTT authentication, DPS API authentication, and message signing and verification for your environment. For connection settings, refer to DSX Agent Deployment Guide.

Hardware access remains part of the DPS deployment. If you use a baseboard management controller (BMC) proxy, including the NVIDIA Infra Controller proxy, configure it through Redfish Proxy Configuration.

The DSX Agent readiness endpoint reports that its health server responds; it does not verify the database, MQTT connection, DPS API, or message delivery. Before accepting the integration, submit an approved signed load target in a test environment and confirm its schedule and status through NvGrid. If power-state publication is enabled, receive the corresponding message on DSX Exchange and verify its signature with the agent public key. Check hardware telemetry when you need to establish the actual power response.