Make DRA_CPUSET env parsing fail closed in NRI

[AutuSnow]

CreateContainer currently logs DRA_CPUSET_* parsing errors but continues as if the container had no DRA CPU allocation, which makes it fall back to the shared CPU pool.

Synchronize has a similar recovery concern: if an existing container has a malformed DRA_CPUSET_* env, the container is skipped while rebuilding allocation state.

This should not happen in the normal path because the env is generated by this driver through CDI, but fail-closed behavior would be safer for corrupted CDI specs, runtime anomalies, or future env contract changes.

Related:

• Support assigned.cpuset exposure via CDI (Parity with KEP-6122) #181
• add CPU request validation in NRI CreateContainer hook #110
• KEP 6122: Configurable Scaling Delay with Pod Resource Exposure KEP creation kubernetes/enhancements#6123

[AutuSnow]

/assign

[ffromani]

This should not happen in the normal path because the env is generated by this driver through CDI, but fail-closed behavior would be safer for corrupted CDI specs, runtime anomalies, or future env contract changes. 

I agree. It IS unlikely, but swallowing errors in the NRI layer makes only things worse because creates issues hard to debug and breaches the workload guarantees.

While hard fail makes sense to me, let's evaluate how the e2e flow would look like. I guess, but let's verify, hard failing in NRI will let containers in CreateContainerError, which would be ok UX-wise and surely better than run with broken promises.

[AutuSnow]

I checked the NRI/containerd path a bit. A non-fatal error returned from the NRI CreateContainer callback should propagate back through CRI container creation, so the expected kubelet-facing result should be CreateContainerError.

I think the next step can be:

• make CreateContainer return an error when parsing a driver-owned DRA_CPUSET_* env fails
• update the current unit test that expects malformed env to fall back to shared CPUs
• add an e2e that injects a malformed DRA_CPUSET_* env and verifies the pod reaches CreateContainerError
  
  One detail worth confirming: should we explicitly document DRA_CPUSET_* as a driver-reserved env prefix? That would make fail-closed behavior less surprising if a user accidentally sets an env with that prefix.
  
  For Synchronize, I think we may want a separate decision. Failing closed during container creation is straightforward, but failing or partially rebuilding state during restart has a different availability tradeoff.

[ffromani]

/reopen

see: #190 (comment)

[kubernetes-prow]

@ffromani: Reopened this issue.

Details

In response to this:

/reopen

see: #190 (comment)

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.