CSI allocatable volume count is static (32) and not attachment-limit aware

Summary

CSINode.spec.drivers[].allocatable.count appears to be a static value (32) for the Block Volume CSI driver, regardless of effective attachment constraints (for example, attachment type and shape-specific limits).

In mixed environments where some workloads/storage classes use paravirtualized block volume attachment and others use iSCSI, this can cause scheduler optimism and runtime attach failures.

Affected code

pkg/csi/driver/bv_node.go (v1.35.0), where maxVolumesPerNode is set to 32 and returned from NodeGetInfo.

Problem

Kubernetes scheduling uses CSI-reported allocatable volume count.
If the driver always reports 32, but the effective limit for a node/workload path is lower (for example, paravirtualized path), pods can be scheduled and then fail during volume attach with cloud-provider LimitExceeded errors.

Expected behavior

The reported allocatable volume count should reflect effective attach capacity for the node/workload path (or provide a safe configurable override), so scheduling and runtime behavior stay consistent.

Request

Would you consider one of the following?

1. Make allocatable count dynamic in NodeGetInfo (shape/attachment-mode aware), or
2. Provide configurable per-node/pool/driver override(s) for allocatable count, or
3. Provide a conservative mode for environments where attach-mode-specific limits differ.

Why this matters

When CSI-reported allocatable count is higher than real attach capacity, stateful workloads can get stuck in attach/retry loops and require manual operational intervention.

Start in pkg/csi/driver/bv_node.go at maxVolumesPerNode and NodeGetInfo. Determine how the effective attachment limit varies by attachment type or node shape, then establish whether dynamic reporting, a configurable override, or conservative mode is the intended approach. Done means the reported allocatable count does not exceed the node's effective attach capacity.