Power Policies#

Power policies control device power and performance behavior. DPS stores current policies in named, typed policy bundles and selects one bundle for an entire topology or resource group. A topology selection is a persisted topology-wide default; it is not an assignment embedded on each entity.

This page describes the current policy model, including what DPS does when no effective policy remains.

Policy Bundles#

For an operator, a policy bundle is a named, reusable set of controls selected for a topology or resource group. Each entry in Policies has a Type, an optional Scope, and the settings for that policy type.

Policy Types#

Type	Operator intent
`ComputerSystemLimits.v1`	Define node and component operating ranges.
`DPM.v1`	Select Dynamic Power Management strategy and power shifting.
`PRS.v1`	Enable or disable Power Reservation Steering.
`APPM.v1`	Select APPM behavior.
`EPD.v1`	Select EPD behavior.
`AggregatePowerLimits.v1`	Define aggregate limits for complete compute nodes.
`WPPS.v1`	Select the complete workload power profile ID set.

Built-In Bundles#

DPS ships three policy bundles:

Bundle	Intended behavior
`MaxP`	Use the full operating ceiling, proportional DPM with power shifting enabled, and PRS disabled.
`MaxQ`	Use model-specific efficiency targets, proportional DPM with power shifting enabled, and PRS disabled.
`MaxLPS`	Use model-specific sustained-power targets, proportional DPM with power shifting enabled, and PRS enabled.

The model-specific limits can differ by system. Inspect the installed bundle before selecting it.

Custom Bundle Example#

The following bundle sets an 80 percent operating target within a 100 percent ceiling, enables proportional DPM and power shifting, and disables PRS:

Name: site-balanced
Policies:
  - Type: ComputerSystemLimits.v1
    OperatingRangePercent:
      Target: 80
      Ceiling: 100
  - Type: DPM.v1
    Strategy: PROPORTIONAL
    PowerShift: ENABLED
  - Type: PRS.v1
    Value: DISABLED

Download site-balanced.yaml.

Manage and Select a Bundle#

List and inspect available bundles, then store one custom bundle:

dpsctl policy bundle list
dpsctl policy bundle get MaxLPS
dpsctl policy bundle upsert site-balanced.yaml

upsert stores the bundle definition; it does not apply the bundle to hardware. After storing it, choose the selection path that matches the object:

To use the bundle as the default for a later Go CLI topology import, or for a later resource-group create that omits --policy-bundle, update global_policy_bundle before creating the object.
To select the bundle only for a new resource group, pass --policy-bundle when creating that group, as shown in Resource-Group Policy Selection.

These are alternative selection paths; setting the global default is not required when the resource group names its bundle explicitly. Refer to bundle for the bundle command summary.

Verify Bundle State#

Verify each layer separately. A successful check at one layer does not prove the next layer:

Question	Go `dpsctl` command	Meaning
Is the definition stored?	`dpsctl policy bundle list` or `dpsctl policy bundle get <name>`	Confirms that the server stores the named bundle definition. It does not confirm selection or allocation.
Which bundle is selected?	`dpsctl topology list` or `dpsctl resource-group list`	Inspect `policy_bundle` to confirm the name persisted on that topology or resource group.
Which policy object is allocated to a target node?	`dpsctl check status --nodes <node>`	Inspect `current_state.allocated_policy_name`. The value identifies an allocated policy object or type, such as `ComputerSystemLimits.v1`; it is not the bundle name.
Which power limits are enforced by the device?	`dpsctl check metrics --nodes <node> --effective`	Inspect the power-limit fields read from the device. This verifies hardware state rather than only stored or allocated state.

Note

The YAML example uses the Go dpsctl file format. SDK clients construct the corresponding typed protobuf policies rather than sending this YAML as an API payload.

Topology Policy Selection#

A topology policy is the named policy bundle persisted on a topology. It applies topology-wide when the topology is active. API clients set the selection with CreateUpdateTopologyRequest.policy_bundle.

When the topology selection is empty, DPS resolves it to the current global_policy_bundle setting and persists the resolved name on the topology. The same empty-value resolution applies to resource-group policy bundles. New deployments set global_policy_bundle to MaxLPS by default.

global_policy_bundle is a default-selection setting, not a global binding. Changing it affects later topology operations that provide an empty bundle value and later resource-group creation that omits the bundle. It does not rewrite selections already persisted on topologies or resource groups, and it does not immediately change running hardware.

Administrators can change the default selection:

dpsctl settings update --set global_policy_bundle=site-balanced

Released Go dpsctl settings update rejects an empty setting value. To remove the global default, use the Web UI removal workflow or an authenticated settings API client. A topology created with no resolved bundle can activate without an effective power-limit policy, in which case the unset behavior described in the following sections applies.

Important

The former topology-file policy model is not an activation interface. A topology import with a nonempty top-level Policies array is rejected. A legacy per-entity Policy value does not create a policy assignment when the topology activates. Manage bundles separately and select a bundle through the current topology or resource-group interface.

Resource-Group Policy Selection#

Select a resource group’s bundle when you create the group:

dpsctl resource-group create \
  --resource-group ml-training-job \
  --external-id 12345 \
  --policy-bundle site-balanced

If --policy-bundle is omitted, the server resolves and persists the current global_policy_bundle.

Policy Composition#

While a topology is active, DPS creates a topology-scoped binding from its selected bundle. An active resource group creates a higher-precedence binding. The composition rule is specific to each policy type: resource-group policies supersede or compose with topology policies by policy type.

The effective policy applies to matching power-managed devices, not to a separate per-entity policy selection stored in the topology definition.

Policy Lifecycle and Fallback#

The following table distinguishes persisted selection from hardware action. Creating or importing a topology stores a selection; activation and release events are what apply policies to devices.

Situation	Core Action	Documented Result
Topology is created or imported	No hardware action	Resolve and persist the explicit topology bundle or the current global default.
Topology activates with an effective policy set	`SetPolicy`	Apply the topology-wide effective policy to matching power-managed devices.
Topology activates without an effective policy	`UnsetPolicy`	Apply `idlePolicy` when configured; otherwise use the plugin-specific unset fallback.
Resource group becomes active	Compose the higher-precedence resource-group binding	Resource-group policies supersede or compose with topology policies by policy type.
Resource group is released with remaining topology limits	`SetPolicy`	Restore the topology-effective policy.
Resource group is released without limits but with `idlePolicy`	`UnsetPolicy`	Apply the device idle policy.
Resource group is released without limits or `idlePolicy`	`SetPolicy` at the hardware minimum	Do not interpret this path as a return to BMC defaults.
Topology deactivates	`UnsetPolicy`	Mark the topology inactive and perform best-effort device cleanup through idle or plugin fallback behavior.

Device Idle Policies#

An idlePolicy is an unnamed fallback in a ComputerSystem device specification. It is not a topology policy and is not a policy bundle. DPS passes it to the device plugin when an unset operation should place the device into its idle state.

ComputerSystemSpec.idlePolicy supports Node, GPU, CPU, and Memory entries. Set exactly one watts or percentage value in each entry. The shipped GB200 specification uses this idle policy:

idlePolicy:
  Node:
    watts: 1000
  GPU:
    watts: 800
  CPU:
    watts: 100

Values must be positive and percentages cannot exceed 100. Node, GPU, and CPU watt values are validated against their device-specification ranges. When all entries use watts and a Node entry is present, the component total cannot exceed the Node value. When all entries use percentages, the component percentages must total 100; if a Node entry is present, it must also be 100. Refer to Device Specifications for the role of device specifications.

A component-only idle policy does not imply a node cap. For example, GPU and CPU idle values without a Node entry configure those components but do not create a node limit that was not specified.

Plugin-Specific Unset Behavior#

UnsetPolicy asks the device plugin to perform cleanup; it does not guarantee a single hardware state across every platform.

Generic Redfish applies idlePolicy when one is configured. Without one, it removes the DPS-managed Redfish policy.
Specialized EnvironmentMetrics plugins can restore platform BMC defaults when no idle policy is available. If applying the idle policy fails, a plugin can restore the BMC defaults and report a warning.

Idle-policy failures therefore vary by plugin and can appear as errors or warnings in device status. Topology deactivation remains best effort: DPS marks the topology inactive and reports cleanup failures rather than reverting it to active.

An empty allocated-policy name in status does not prove that the device is uncapped. An idle policy or a plugin-restored BMC default can still be active even though no named bundle is allocated.