Support assigned.cpuset exposure via CDI (Parity with KEP-6122)

[pravk03]

kubernetes/enhancements#6123 is introducing a new field assigned.cpuset to the downward API. This allows containers to discover their exclusive CPU assignments by reading a file projected into the pod. To achieve parity, the DRA driver should expose this information using CDI. This is likely possible through containerEdits.mounts but opening this issue to explore more. We can target this change for a release version with 1.37 or later.

xref from discussion in kubernetes/enhancements#6123 (comment)

[fmuyassarov]

If you haven't yet decided to add it yourself, I would be happy to work on this @pravk03

[pravk03]

Thanks @fmuyassarov. Please feel free to take it up :)

[ffromani]

strong +1 to the concept. Arguably, we explictly expose something already available to the workload - just inspect the cpus in the self cgroup - but it's a good QoL improvement.

Just to be obvious, I think we should surface the value indeed, but due to the operational differences I think is fair (or perhaps just required) to use a different vehicle wrt what KEP 6122 will do.

I personally I'd be open to report the cpusets in 0.3.0/before 1.37 is out and then align as much as possible when KEP 6122 becomes alpha/beta. Random thought: add environment variables now (=0.3.0), align using mounts/projected volumes/whatever later.

[fmuyassarov]

/assign

[AutuSnow]

I checked the current driver code: we already expose the allocated cpuset through CDI ContainerEdits.Env as DRA_CPUSET_<claimUID>=<cpuset>, and NRI also relies on that env to rebuild claim allocation state during synchronize/restart.

So I think this issue is less about whether CDI can expose the data, and more about defining a stable user-facing contract. The current env is claim-scoped and tied to claim UID; assigned.cpuset is more like an aggregate per-container view.

For 0.3.0, env-based exposure seems sufficient because DRA CPU assignments are fixed at prepare time. I would keep the existing DRA_CPUSET_<claimUID> env for internal/runtime compatibility, and optionally add/document a stable aggregate env such as DRA_CPUSET_ASSIGNED=<union>. Then we can revisit CDI mounts / file-based exposure later to align more closely with KEP-6122.