DPS 0.9.0 Release Notes#

  • Release date: September 11, 2026

  • Previous release: DPS 0.8.3

DPS 0.9.0 introduces MaxLPS: policy-driven dynamic power management, an improved policy interface, expanded observability dashboards and alerting, Redfish proxy support, Vera Rubin platform support, improved dynamic power allocation, and new authentication and transport-security capabilities.

These notes cover DPS 0.9.0.

Important Upgrade Information for MaxLPS Power Pilots#

Upgrading a MaxLPS Pilot Deployment From DPS 0.8.x#

For MaxLPS pilot test deployments, it is generally safe to deactivate the DPS 0.8.x topology, uninstall the DPS 0.8.x Helm release, and install a DPS 0.9 deployment. Before deactivating the topology, deactivate every active resource group that contains entities in that topology. Treat this process as a clean replacement rather than an in-place upgrade. Retain the topology, policy, credential, database, and Helm values that the pilot must preserve before uninstalling. This procedure is not a substitute for an approved production backup and recovery plan.

Deploy DPS Core (the DPS server) and ensure that at least one DPS agent is connected. The chart deploys DPS Core and its ingress (dps.enabled: true, dps.ingress.enabled: true), the DPS UI and its ingress (ui.enabled: true, ui.ingress.enabled: true), bundled PostgreSQL with persistent storage (postgresql.enabled: true), and the Power Steering 2.1 subchart (power-steering.enabled: true) by default. To deploy an agent in the same cluster as DPS Core, set agent.enabled: true when you install or upgrade the chart. Unless overridden, the agent connects to the release’s DPS gRPC service.

For configuration and client-transition details for the DPS 0.9 deployment, refer to Further Upgrade Information.

Review the Default Policy Bundle#

New DPS 0.9.0 deployments set global_policy_bundle to MaxLPS. When a topology is created or imported, or a resource group is created, with an empty policy-bundle selection, DPS resolves that selection to the current global setting and persists the resolved bundle name. An explicit empty selection on a deactivated topology update resolves the same way.

For a retained DPS 0.8.x database, this resolution also occurs during 0.9.0 recovery for existing topologies and resource groups whose stored selection is empty. DPS persists the resolved name and recreates the policy binding for active objects. Existing nonempty policy-bundle selections are not rewritten; likewise, a persisted global_policy_bundle value, including an intentionally empty value, takes precedence over the shipped MaxLPS default.

The resolved topology bundle becomes the topology-wide policy when the topology is active. A resolved resource-group bundle is the resource group’s higher-precedence policy binding, which composes with or supersedes topology policies by policy type. MaxLPS is therefore a default-selection mechanism, not a live global policy binding. Before retaining a DPS 0.8.x database, or creating or importing new objects, inspect the available bundles and the current setting. Test the resulting selections in a non-production copy, then set a different default only when it matches the deployment’s intended policy:

dpsctl policy bundle list
dpsctl settings list
dpsctl settings update --set global_policy_bundle=MaxP

Added#

Policy-Driven Power Management#

  • Introduced a typed policy framework based on policy bundles, bindings, scopes, composition, and effective-policy inspection.

  • Added support for Computer System Limits, Dynamic Power Management, and Aggregate Power Limits policy models.

  • Added ComputerSystemLimits.v1 floor, target, and ceiling specifications for node, GPU, CPU, and memory power. Node ranges can use watts or a percentage of the hardware maximum. Component ranges can use watts or a percentage of the node ceiling. GPU watt values apply to the aggregate GPU budget of one ComputerSystem, not to each GPU separately.

  • Enforced the operating-range contract floor <= target <= ceiling. A node target is a desired operating point within the hardware-clamped range. Component targets become requested GPU, CPU, or memory policy values when supplied. Floors and ceilings constrain policy composition, admission, and redistribution rather than independently programming component setpoints.

  • When multiple limits apply, DPS uses the most restrictive valid range: the highest floor and the lowest non-zero target and ceiling. DPS rejects incompatible combinations rather than relaxing them.

  • Added default policy bundles — MaxP, MaxQ, and MaxLPS — that provide model-specific Computer System Limits ranges.

  • Improved the policy interface across the UI, CLI, and APIs with effective-policy inspection, policy-bundle management, and resource-group policy-bundle attachment.

  • Enabled MaxLPS settings by default and changed the default Dynamic Power Management strategy to proportional.

MaxLPS Dynamic Power Management#

  • Delivered the first release of MaxLPS policy-driven dynamic power management, combining the MaxLPS policy bundle with dynamic power allocation for dynamic GPU-power redistribution.

  • Upgraded the embedded PRS deployment with the independently versioned power-steering Helm subchart, version 2.1.0.

Hardware, BMC, and Agent Operations#

  • Added support for Vera Rubin NVL72, including catalog, power-plugin, and BMC-health support.

  • Added durable GPU hardware-identity discovery and Redfish GPU UUID exposure through DPS APIs, metrics, resource groups, and policy-update results.

  • Added the DPS agent control-plane service, remote device configuration, agent discovery API and CLI support, and node-compliance alerts.

  • Added configurable per-node BMC-health timeouts.

Authentication, Security, and Observability#

  • Added OIDC/JWKS validation, dpsctl client-credentials and browser device-code login, and OIDC PKCE support in the UI.

  • Added LDAP group profiles, browser-session logout and revocation, refresh-token rotation, and replay detection.

  • Added BMC client CA and client-certificate support, per-connection TLS-verification controls, server TLS version and cipher validation, and optional secured Prometheus metrics access.

  • Improved observability dashboards and alerting with Grafana handoffs for power compliance, BMC latency, traces, and server health; active-resource-group priority metrics; NvGrid unmet-budget reasons; and node-compliance alerts.

UI and SDKs#

  • Modernized the bundled UI with policy-bundle management, BMC-health workflows, agent views, topology and inventory workflows, and expanded NvGrid views.

  • Added a Go client, typed C/C++ API error codes, and updated Python service APIs.

Improved#

  • Added Agent metrics scraping and trace propagation.

  • Improved topology handling and GPU policy updates.

  • Improved GPU policy application by staging reductions and increases, applying fixed GPU targets on supported platforms, and returning an explicit in-progress result when a dpsctl deadline expires while the server continues the update.

  • Moved Redfish telemetry to the platform environment-metrics endpoint where applicable.

  • Added Redfish proxy support, Redfish URL overrides, proxy-aware transport, and retries for proxy-connectivity failures.

  • Improved BMC-policy persistence, telemetry-failure handling, partial-BMC-loss handling, tracing, and metric-cardinality control.

  • Changed BMC health checks to report telemetry sampling failures as check failures.

Fixed#

  • Corrected stale or invalid platform-telemetry handling and bounded Redfish operation latency.

  • Corrected resource-group activation, deactivation, deletion, and topology-validation failure handling.

  • Corrected BMC session and bearer-token lifecycle handling, GPU policy timeout reporting, proxy retry behavior, and fixed-target GPU actuation.

  • Hardened JWT metadata parsing, LDAP authentication, BMC TLS verification, dependency versions, and UI runtime dependencies.

Deprecated#

  • Legacy single-policy fields are deprecated in favor of Policy Bundles.

Known Issues#

  • ResourceGroupUpdate cannot change a resource group’s policy bundle in DPS 0.9. Support is planned for a future release.

Further Upgrade Information#

Update Telemetry Settings#

If your Helm values use dps.telemetry.provider, remove it. Use dps.telemetry.metrics.source instead.

Review Power Steering Defaults#

The MaxLPS power steering controller implements dynamic power allocation and is enabled by default and uses a 5-second allocation interval.

If dynamic power allocation MUST remain disabled, explicitly set both dps.prs.enabled and power-steering.enabled values to false before you deploy the replacement release.

The embedded prs subchart is replaced by the independently versioned power-steering subchart. Migrate custom prs.* values to their power-steering.* equivalents. In-cluster service names change from *-prs-config and *-prs-controller to *-power-config and *-power-controller. Preserve explicit dps.prs.hostPort and dps.prs.controllerHostPort overrides where needed.

The updated power steering controller changes v2 Prometheus metric families from prs_* to power_steering_*. Update dashboards, recording rules, and alerts accordingly. Some metric names require more than a mechanical prefix replacement.

Configure Production Authentication and TLS#

DPS 0.9 does not generate gRPC TLS material. Server tls and mtls require dps.serverTLS.existingSecret with tls.crt, tls.key, and ca.crt. Agent tls requires agent.tls.existingSecret with ca.crt. Agent mtls requires ca.crt, tls.crt, and tls.key.

The default chart is intended for bring-up only. Server and agent transport default to insecure, and an empty dps.auth.authenticatorType resolves to alwaysAllow unless LDAP is enabled. Production deployments must configure TLS or mTLS, LDAP or OIDC authentication, and an HTTPS UI ingress.

Upgrade Clients and Build Environments#

Regenerate or upgrade gRPC, Python, Go, and C/C++ clients for the DPS 0.9 API. Device-controller legacy single-policy fields are deprecated. Use complete effective-policy snapshots instead.

Revalidate UI automation and custom UI integrations because the bundled application uses UI v2 and a Node-based /api proxy.