docs(gpu): select the container variant from bundle values - #714
Aleksei Sviridkin (lexfrei) wants to merge 1 commit into
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configuration
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
✅ Deploy Preview for cozystack ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
IvanHunters
left a comment
IvanHunters
left a comment
There was a problem hiding this comment.
LGTM
Docs-only change, and I checked it against current cozystack/cozystack main. Reversing the old claim is right: the iaas bundle now accepts gpuOperatorVariant: container, so the previous "container makes the platform chart fail the Helm render" line had gone stale. The render guard in packages/core/platform/templates/bundles/iaas.yaml allows exactly default, vgpu and container, and packages/core/platform/sources/gpu-operator.yaml carries a real container variant with its own values-container.yaml. The page lives under docs/next, so tracking main is the correct baseline. Netlify preview builds clean too.
What else held up: the KubeVirt wiring block is gated on the variant not being container, so the container path gets no HostDevices feature gate and no permittedHostDevices table. spec.variant and spec.components.<name>.values are what the platform Package helper emits, so the CR example is accurate. The internal link to the container-workloads page resolves.
Two non-blocking notes inline.
|
|
||
| The bundle leaves the `KubeVirt` CR untouched for this variant: no `HostDevices` feature gate and no `permittedHostDevices` table. The host driver stays bound, so no GPU on the node can be passed through to a VM. | ||
|
|
||
| If you need to override something the bundle does not expose (driver settings, custom node selectors, validator or dcgmExporter tweaks), hand-craft a `Package` CR named `cozystack.gpu-operator` with `variant: container` instead, and put the overrides under `spec.components.gpu-operator.values`. The platform controller installs it without a bundle entry: |
There was a problem hiding this comment.
[MINOR] override path is one level too shallow
The overrides belong one level deeper: spec.components.gpu-operator.values.gpu-operator.<key>. The gpu-operator package is an umbrella chart whose settings live under a nested gpu-operator: key (see its values.yaml and values-container.yaml), and the bundle itself forwards overrides as components.gpu-operator.values.gpu-operator.* in packages/core/platform/templates/bundles/iaas.yaml. So the examples you list (driver settings, validator, dcgmExporter tweaks) placed directly under spec.components.gpu-operator.values would be silently ignored by the chart. Worth a one-line correction so the override actually takes effect.
There was a problem hiding this comment.
IvanHunters Checked against main: iaas.yaml forwards components.gpu-operator.values.gpu-operator, and every values file in the package sits under gpu-operator:. The page now uses that path, and the sample Package shows where the overrides go.
| - cozystack.gpu-operator | ||
| ``` | ||
|
|
||
| The bundle leaves the `KubeVirt` CR untouched for this variant: no `HostDevices` feature gate and no `permittedHostDevices` table. The host driver stays bound, so no GPU on the node can be passed through to a VM. |
There was a problem hiding this comment.
[NIT] "untouched" reads as "not deployed"
The KubeVirt CR is still emitted for the container variant, with its base values (cpuAllocationRatio, disabledFeatureGates, migrations); only the GPU wiring is skipped. "leaves the KubeVirt CR untouched" can read as "KubeVirt is not deployed". The clause right after it scopes the claim to the GPU wiring, so this is purely cosmetic.
There was a problem hiding this comment.
Reworded: the bundle still renders the KubeVirt CR with its base settings and only skips the GPU wiring.
24b9bdd to
b7f62da
Compare
The iaas bundle now accepts bundles.iaas.gpuOperatorVariant: container, so the container workloads page points readers at the bundle and keeps the hand-written Package CR only for overrides the bundle does not expose. The passthrough and vGPU pages described the KubeVirt HostDevices gate and permittedHostDevices table as following from enabling gpu-operator. That now holds for the default and vgpu variants only; container keeps the host driver bound and gets no KubeVirt wiring. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin <f@lex.la>
b7f62da to
7b26159
Compare
This branch has not been deployed
2 participants
The container GPU variant can now be set up through the bundle, and the docs say so. cozystack/cozystack#4101 made the
iaasbundle acceptgpuOperatorVariant: container, so a hand-written Package CR is no longer the only way to get it. The same change stopped rendering the KubeVirtHostDevicesgate andpermittedHostDevicestable forcontainer. Onlydefaultandvgpuget them.The container workloads page now shows the bundle values and keeps the Package CR for overrides the bundle does not expose. The passthrough and vGPU pages say which variants get the KubeVirt wiring.
Only
next/is changed. The fix is on cozystackmainand not in any v1.6.x tag, so thev1.6/pages still describe the released behaviour.Closes #685