bundles.iaas.gpuOperatorVariant is getting a third accepted value, container, in an upstream fix to the iaas bundle guard. Three pages under content/en/docs/next/ say it does not accept one.
operations/gpu-container-workloads.md is the one that actually misleads. Step 1 tells the reader not to put cozystack.gpu-operator in bundles.enabledPackages, says the bundle only takes default or vgpu, and sends them to a hand-written Package CR. After the fix the bundle is the supported path, and the hand-written CR is only for overrides the bundle does not expose.
virtualization/gpu.md and virtualization/vgpu.md describe the KubeVirt host-device wiring as a consequence of enabling the operator. That holds for default and vgpu. It does not hold for container, which gets the Package and no wiring at all: the host driver stays bound, so no GPU can reach a VM.
The v1.6 copies describe released behaviour and stay as they are. Only next needs the edit, and only once the fix ships in a release, which is why this is an issue and not a PR.
bundles.iaas.gpuOperatorVariantis getting a third accepted value,container, in an upstream fix to theiaasbundle guard. Three pages undercontent/en/docs/next/say it does not accept one.operations/gpu-container-workloads.mdis the one that actually misleads. Step 1 tells the reader not to putcozystack.gpu-operatorinbundles.enabledPackages, says the bundle only takesdefaultorvgpu, and sends them to a hand-written Package CR. After the fix the bundle is the supported path, and the hand-written CR is only for overrides the bundle does not expose.virtualization/gpu.mdandvirtualization/vgpu.mddescribe the KubeVirt host-device wiring as a consequence of enabling the operator. That holds fordefaultandvgpu. It does not hold forcontainer, which gets the Package and no wiring at all: the host driver stays bound, so no GPU can reach a VM.The
v1.6copies describe released behaviour and stay as they are. Onlynextneeds the edit, and only once the fix ships in a release, which is why this is an issue and not a PR.