hashicorp/nomad · error

unable to provision %q in accessible_topology: %v

Error message

unable to provision %q in accessible_topology: %v

What it means

ControllerCreateVolume received gRPC code ResourceExhausted from the CSI plugin, meaning the plugin could not provision the volume within the requested accessible_topology — typically out of capacity, quota, or available nodes/zones. Nomad wraps it with this message naming the topology constraint.

Source

Thrown at plugins/csi/client.go:451

	// meanings, so translate them into user-understandable terms
	// https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume-errors
	if err != nil {
		code := status.Code(err)
		switch code {
		case codes.InvalidArgument:
			return nil, fmt.Errorf(
				"volume %q snapshot source %q is not compatible with these parameters: %v",
				req.Name, req.ContentSource, err)
		case codes.NotFound:
			return nil, fmt.Errorf(
				"volume %q content source %q does not exist: %v",
				req.Name, req.ContentSource, err)
		case codes.AlreadyExists:
			return nil, fmt.Errorf(
				"volume %q already exists but is incompatible with these parameters: %v",
				req.Name, err)
		case codes.ResourceExhausted:
			return nil, fmt.Errorf(
				"unable to provision %q in accessible_topology: %v",
				req.Name, err)
		case codes.OutOfRange:
			return nil, fmt.Errorf(
				"unsupported capacity_range for volume %q: %v", req.Name, err)
		case codes.Internal:
			return nil, fmt.Errorf(
				"controller plugin returned an internal error, check the plugin allocation logs for more information: %v", err)
		}
		return nil, err
	}

	return NewCreateVolumeResponse(resp), nil
}

func (c *client) ControllerListVolumes(ctx context.Context, req *ControllerListVolumesRequest, opts ...grpc.CallOption) (*ControllerListVolumesResponse, error) {
	if err := c.ensureConnected(ctx); err != nil {
		return nil, err

View on GitHub (pinned to 482b49bf1a)

Solutions

  1. Free capacity: delete unused volumes/snapshots in the target zone or increase the storage pool.
  2. Raise the provider quota (volumes, capacity, IOPS) for the account/zone.
  3. Relax or widen the accessibility_requirements topology in the volume spec (e.g. allow more zones).
  4. Provision in a different zone/topology segment and update the volume spec accordingly.

Example fix

// before (single zone, exhausted)
topology_request {
  preferred { segments { topology = "zone/us-east-1a" } }
}
// after (allow another zone)
topology_request {
  preferred { segments { topology = "zone/us-east-1b" } }
}
Defensive patterns

Strategy: retry

Validate before calling

// Verify the requested topology segment has capacity (via plugin/backend API) before creating
for _, seg := range req.AccessibleTopology {
    if !zoneHasFreeCapacity(seg) {
        return fmt.Errorf("topology segment %v has no free capacity", seg)
    }
}

Try / catch

vol, err := client.ControllerCreateVolume(ctx, req)
if err != nil && strings.Contains(err.Error(), "in accessible_topology") {
    // back off and retry, or retry with a relaxed/different topology
}

Prevention

When it happens

Trigger: Calling ControllerCreateVolume with accessibility_requirements (topology) where the plugin returns codes.ResourceExhausted — e.g. no more space in the requested zone, quota exceeded, or no node in the required topology segment can host the volume.

Common situations: Storage pool or zone is full; cloud quota for volumes/IOPS exhausted; topology constraint names a segment (zone/rack) with no available storage; many jobs provisioning concurrently in one region.

Related errors


AI-assisted analysis of hashicorp/nomad@482b49bf1a (2026-09-04). Data as JSON: /api/errors/fc26758cf7429276. Report an issue: GitHub.