https://deploy-preview-1127--dra-driver-nvidia-gpu.netlify.app/contribute/proposals/Recent content in Enhancement proposals on DRA Driver for NVIDIA GPUsHugoenhttps://deploy-preview-1127--dra-driver-nvidia-gpu.netlify.app/contribute/proposals/nnnn-template/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-1127--dra-driver-nvidia-gpu.netlify.app/contribute/proposals/nnnn-template/<!-- Before writing this, pause and check: - Does this change really belong in this driver? A common outcome for proposals here is "wrong layer" — the change really belonged in upstream Kubernetes, in the device plugin, or in the GPU operator. If you're not sure, open a discussion issue first and link it here. - If you can't yet write a one-paragraph release note for this change, you aren't ready to propose it. - Small changes (a flag, a config knob, a local refactor) go straight to a PR. See docs/proposals/README.md for when a proposal is actually needed. --> <table> <thead> <tr> <th>Field</th> <th>Value</th> </tr> </thead> <tbody> <tr> <td>Status</td> <td>provisional</td> </tr> <tr> <td>Authors</td> <td>@your-handle</td> </tr> <tr> <td>Created</td> <td>YYYY-MM-DD</td> </tr> <tr> <td>Related issues</td> <td>#…</td> </tr> </tbody> </table> <h2 id="summary">Summary</h2> <!-- One paragraph. Should read like the release note users will see on merge — write this first. If you can't, you don't understand the change yet. --> <h2 id="motivation">Motivation</h2> <h3 id="who-is-asking-for-this-and-why">Who is asking for this, and why?</h3> <!-- Name a concrete workload, a named downstream consumer (for example KubeVirt, LWS, JobSet, Slurm, DCGM-Exporter), or a specific user class. Abstract motivation without a named use case is a common reason proposals stall. --> <h3 id="goals">Goals</h3> <!-- Each goal should be measurable enough to imply a test. "How will we know this has succeeded?" is the question reviewers will ask. --> <h3 id="non-goals">Non-goals</h3> <!-- Explicit fence. What are you NOT proposing, even if related? This is where you prevent scope creep during review. --> <h2 id="why-this-belongs-in-the-nvidia-dra-driver">Why this belongs in the NVIDIA DRA driver</h2> <!-- Required. State why this change lives here and not in: - upstream Kubernetes / DRA core - the device plugin - the GPU operator - a CLI or external tool If any part of this requires an upstream Kubernetes change, link the blocking issue or discussion. --> <h2 id="proposal">Proposal</h2> <h3 id="user-facing-example">User-facing example</h3> <!-- Required. Show the concrete surface users will touch: a ResourceClaim manifest, a CRD sample, a CLI invocation, a Helm values snippet. If this feels verbose or repetitive, that's a signal the UX needs rework before the internals do. --> <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-yaml" data-lang="yaml"><span class="line"><span class="cl"><span class="c"># example</span><span class="w"> </span></span></span></code></pre></div><h3 id="affected-components">Affected components</h3> <!-- Check all that apply. Matches the components dropdown on the feature request issue form. --> <ul> <li><input disabled="" type="checkbox"> <code>api/</code> — CRDs, CRD fields, or ResourceClaim shape</li> <li><input disabled="" type="checkbox"> <code>gpu-kubelet-plugin</code></li> <li><input disabled="" type="checkbox"> <code>compute-domain-kubelet-plugin</code></li> <li><input disabled="" type="checkbox"> <code>compute-domain-controller</code></li> <li><input disabled="" type="checkbox"> <code>compute-domain-daemon</code></li> <li><input disabled="" type="checkbox"> admission webhook</li> <li><input disabled="" type="checkbox"> Helm chart (<code>deployments/helm</code>)</li> <li><input disabled="" type="checkbox"> CDI spec generation</li> <li><input disabled="" type="checkbox"> Metrics</li> <li><input disabled="" type="checkbox"> Kubelet-plugin checkpoint schema</li> <li><input disabled="" type="checkbox"> Documentation</li> <li><input disabled="" type="checkbox"> CI / testing</li> </ul> <h3 id="authoritative-state-owner">Authoritative state owner</h3> <!-- For any new persistent or runtime state: which single component is authoritative for writes? How do the others read it? Reviewers will push back on state split across plugin + controller + daemon without a clear owner. If you haven't worked in this codebase before, the top-level README and the directories under `cmd/` describe what each component does. --> <h3 id="smallest-valuable-slice">Smallest valuable slice</h3> <!-- What is the smallest piece that could ship first and still be useful? Large PRs routinely get asked to split — plan the decomposition now. --> <h2 id="design">Design</h2> <h3 id="api-changes">API changes</h3> <!-- List new or changed CRD fields, flags, annotations, Helm values. For each new field, explicitly label it "user-facing" or "implementation detail." Default to NOT exposing speculative fields — once users depend on them, removal is painful. --> <h3 id="feature-gate--graduation">Feature gate &amp; graduation</h3> <!-- Does this introduce a feature gate? If yes: - Target stability at ship time (Alpha / Beta / Stable). - If not Stable, what does graduation to the next level require? Use the project's three criteria (see docs/proposals/README.md): feature completeness, interoperability (name the adjacent features), stability and soak time. - Which existing feature gates is this mutually exclusive with, or does it compose with? If no gate, state what the change is guarded by (flag, config, chart value) or "none — ships on by default." --> <h3 id="upgrade--downgrade">Upgrade &amp; downgrade</h3> <!-- What happens if a cluster upgrades (or rolls back) the driver while claims are in flight? - If the kubelet-plugin checkpoint schema changes: use `omitempty` on new fields and describe the upgrade test. - Helm value migrations, CRD conversion, RBAC changes. - Rolling restart of controller replicas — does anything get lost? --> <h3 id="environment-floor">Environment floor</h3> <!-- - Minimum NVIDIA driver version. - GPU generations supported (A100 / H100 / B200 / GB200 / L40 / …). - MIG / NVLink / IMEX / fabric requirements. - Minimum Kubernetes version. - Required or assumed kubelet/controller feature gates. --> <h3 id="test-plan">Test plan</h3> <!-- Reviewers will not approve without a concrete plan across more than unit tests. Name the specific files/jobs where you can. - Unit: … - Integration / controller tests: … - BATS (`tests/bats`): … - Mock NVML CI (`hack/ci/mock-nvml`): can this be exercised on CPU-only runners? If no, why not? - Lambda e2e on real GPUs: which `pull-dra-driver-nvidia-gpu-*` job, and which scenario (MIG / time-slicing / ComputeDomain / …)? --> <h2 id="risks">Risks</h2> <!-- Think broadly. Concerns reviewers consistently raise here: - Races between kubelet prepare/unprepare and controller/daemon state. - Force-deleted pods, node reboots, or daemon restarts mid-claim. - Multi-node coordination for ComputeDomains (SSA mutation cache, DNS index collisions, leader election under partition). - Privilege surface: privileged containers, /dev mounts, NVML access, nvidia-container-runtime interactions. - Fail-fast preservation: does the process still exit non-zero on well-defined fatal conditions after this change? --> <h2 id="alternatives">Alternatives</h2> <!-- What did you rule out, and why? Include at minimum: - What you tried with existing primitives (CEL selectors, `matchAttribute`, current CRD knobs, Helm values) and why they were insufficient. - Adjacent prior art in NVIDIA repos — go-nvlib, dra-example-driver, sandbox-device-plugin, nvml-mock — and whether any of it can be reused. - Relevant upstream Kubernetes work, even if only to state "considered, not applicable because …". --> <h2 id="drawbacks">Drawbacks</h2> <!-- Steelman the case against this change. If you can't find one, the proposal isn't ready. --> <h2 id="open-questions">Open questions</h2> <!-- Anything you want explicit maintainer input on before implementation. These are the conversations worth having here rather than in code review. -->