fix: forward hostNQN/DHCHAP secrets on connect and fix allowed-node scheduling

[boddumanohar]

The bug

NodeStageVolume already computes a per-Kubernetes-node host NQN (nqn.2014-08.io.simplyblock:uuid:<Node UID>) and sends it to the control plane's /connect endpoint as host_nqn — the exact NQN the operator registers into a DHCHAP pool's allowed_hosts. The control plane resolves that host's DHCHAP secret and bakes --hostnqn=/--dhchap-secret=/--dhchap-ctrl-secret= into LvolConnectResp.Connect for it.

connectViaNVMe never used any of that — it built the real nvme connect invocation from only transport/IP/port fields, with no --hostnqn and no DHCHAP secret. Without an explicit --hostnqn, nvme-cli fell back to /etc/nvme/hostnqn, seeded once per node by the CSI DaemonSet's postStart hook with an unrelated legacy NQN — a different identity than what the operator registers as allowed. Net effect: DHCHAP-gated (and any allowed_hosts-restricted) volumes could not be mounted through the CSI driver at all.

The fix

dhchapAuthArgs (csi-driver/pkg/util/initiator.go) extracts the host-identity/DHCHAP flags the control plane already computed out of LvolConnectResp.Connect and connectViaNVMe appends them to the real connect command. Pure addition of flags — non-gated pools and existing connections are unaffected.

Two more issues surfaced while verifying this live, both fixed in the same PR:

• hostid/hostnqn kernel collision. nvme-cli falls back to the node's shared, file-seeded default hostid whenever --hostid isn't passed explicitly, regardless of --hostnqn. The kernel enforces a strict per-node 1:1 hostid↔hostnqn consistency (nvme_fabrics: found same hostid ... but different hostnqn), so a node with any pre-existing default-identity connection rejected every later connect naming an explicit, different hostnqn — exactly what DHCHAP needs. hostIDFromHostNQN now derives --hostid from --hostnqn's own UUID, so every connect on a node converges to one internally-consistent pair instead of colliding with the shared default.
• Allowed-node scheduling gap. A DHCHAP pool's first-ever allowed node didn't get correct PersistentVolume.spec.nodeAffinity, because that value used to be read out of CreateVolume's AccessibilityRequirements — which Kubernetes only populates for topology keys already registered in the node's CSINode object at CSI plugin registration time. dhchapAllowedNodeSegment now builds the segment directly from the StorageClass's dhchap_node_label parameter instead, since the value is always the same fixed constant and the key is already known — no dependency on CSI topology registration, and no need to restart the csi-node DaemonSet pod to force it (which would have been node-wide disruptive: it services every pool's volumes on that node, not just the one that changed).

Guardian's reconnect path (resolveExpectedPathCount, recoverPathsWithANA) resolves the same per-node hostNQN via NodeHostNQN, so a DHCHAP volume's automatic reconnect after a transient path drop authenticates correctly too — not just the initial connect.

See operator/docs/designs/design-dhchap.md for the full design, worked examples (StoragePool → generated StorageClass → nvme connect command), and the exact error a future scheduling bug would produce.

e2e coverage

SPDKCSI-DHCHAP in the csi-driver e2e suite (e2e/dhchap.go), two specs:

• Connect/auth: a DHCHAP pool allowing one host NQN — the allowed host mounts and writes successfully, an unauthorized host NQN is genuinely rejected by /connect, and the guardian reconnects a dropped path using the same authorized identity with data intact.
• Scheduling: labels a node the way the operator labels a DHCHAP pool's allowed nodes — with no pod restart — sets the matching StorageClass parameter, pins the first pod there, asserts the PV got the expected nodeAffinity, then strips the pin and recreates the pod to confirm nodeAffinity alone keeps it on the same node.

Not yet wired into CI (no csi-driver e2e job exists yet) — for manual verification against a live cluster.

Test plan

• go build ./..., go vet ./..., gofmt -l clean in csi-driver and operator
• go test (both modules, envtest included for operator) passes, including TestNodeHostNQNComputesAndCaches, TestNodeHostNQNRetriesAfterFailure, TestDHCHAPAllowedNodeSegment
• golangci-lint run clean in both modules
• make helm-sync clean
• Verified end-to-end on two live clusters: both SPDKCSI-DHCHAP e2e specs pass, including the no-restart scheduling fix confirmed on a fresh cluster — labeling a node with zero pod restarts still produced correct PV nodeAffinity on the first attempt

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.