-
Notifications
You must be signed in to change notification settings - Fork 36
docs(gpu): select the container variant from bundle values #714
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -44,9 +44,20 @@ With `driver.enabled=false` the operator uses the pre-installed host driver at i | |
|
|
||
| ## 1. Install the GPU Operator (container variant) | ||
|
|
||
| **Do not** add `cozystack.gpu-operator` to `bundles.enabledPackages` for this variant. The `iaas` bundle renders the GPU operator from `bundles.iaas.gpuOperatorVariant`, which only accepts `default` or `vgpu` — any other value, `container` included, makes the platform chart fail the Helm render (`packages/core/platform/templates/bundles/iaas.yaml`). Apply the `Package` CR directly instead; the platform controller installs it without a bundle entry and without the variant restriction. | ||
| The platform's `iaas` bundle deploys the gpu-operator Package CR when `cozystack.gpu-operator` is in `bundles.enabledPackages` and not in `bundles.disabledPackages`, with the variant taken from `bundles.iaas.gpuOperatorVariant`. Set it to `container` in the Platform Package values, and add `cozystack.gpu-operator` to your existing `enabledPackages` list rather than replacing it: | ||
|
|
||
| Apply a `Package` CR with `variant: container`: | ||
| ```yaml | ||
| bundles: | ||
| iaas: | ||
| enabled: true | ||
| gpuOperatorVariant: container | ||
| enabledPackages: | ||
| - cozystack.gpu-operator | ||
| ``` | ||
|
|
||
| For this variant the bundle still renders the `KubeVirt` CR with its base settings, but adds no GPU wiring to it: 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 leave `cozystack.gpu-operator` out of `bundles.enabledPackages` so the platform release does not also manage that Package and overwrite your changes. Put the overrides under `spec.components.gpu-operator.values.gpu-operator` (the package wraps the upstream chart, so its settings sit under a nested `gpu-operator` key). The platform controller installs it without a bundle entry: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. [MINOR] The "overwrite your changes" rationale contradicts vgpu.md and is not what the shipped helm-controller does The instruction itself (keep |
||
|
|
||
| ```yaml | ||
| apiVersion: cozystack.io/v1alpha1 | ||
|
|
@@ -55,6 +66,10 @@ metadata: | |
| name: cozystack.gpu-operator | ||
| spec: | ||
| variant: container | ||
| components: | ||
| gpu-operator: | ||
| values: | ||
| gpu-operator: {} # upstream gpu-operator chart overrides | ||
| ``` | ||
|
|
||
| ```bash | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[MINOR] No transition note for readers who already applied the Package by hand
The released
v1.6page (and this page before the PR) told the reader tokubectl applyacozystack.gpu-operatorPackage and to stay out ofenabledPackages. A reader with that object who now follows step 1 ends up with the platform release adopting it: it gainshelm.sh/resource-policy: keepand helm ownership annotations, and anyspec.componentsoverrides they had set keep applying silently, since the bundle renders none forcontainer. One sentence saying "if you applied the Package by hand on an earlier release, the bundle adopts it; remove or move yourspec.componentsoverrides first" would close the gap between the two documented flows.