Files
cozystack/packages/core/platform/values.yaml
Aleksei Sviridkin 6935df8c7f chore(kubevirt): update KubeVirt to v1.9.0 (#4015)
## What this PR does

KubeVirt operator manifest goes from v1.8.4 to v1.9.0. The 1.9 release
turns every Beta feature gate on by default and adds
`disabledFeatureGates` to the CR for opting out, so the CR side needed a
few decisions.

`Template` is disabled. With it on, virt-operator deploys virt-template:
two Deployments, two APIServices, a webhook and a
ValidatingAdmissionPolicy that nothing here uses. One more aggregated
API server is one more way to break discovery. This one is not a knob.
`- Template` is written into the CR unconditionally and there is no
value that takes it back out, because nothing on the platform uses
VirtualMachineTemplate; if something starts to, the static entry becomes
a value then. Asking for it through `extraFeatureGates` is refused at
render time with an error that says so, rather than producing a CR
KubeVirt would reject.

`ImageVolume` is the host-dependent one: off below Kubernetes 1.35, left
on from 1.35, with a platform value for runtimes that cannot serve image
volumes even there (#3190 has the k3s case). Nothing the platform ships
uses containerDisk. The value is `kubevirt.disabledFeatureGates` on the
platform values, which the iaas bundle forwards into the emitted
`cozystack.kubevirt` Package as
`components.kubevirt.values.disabledFeatureGates`:

Closes #3190.

```yaml
kubevirt:
  disabledFeatureGates:
  - ImageVolume
```

The chart refuses to render a CR that names one gate in both lists.
KubeVirt's `kubevirt-update-validator.kubevirt.io` webhook rejects that
combination and runs with `failurePolicy: Fail`, so on a cluster that
already has the CR the write is refused and the `kubevirt` HelmRelease
stops converging with everything else the CR carries. The create
admitter runs no validation at all (its own comment says the update
validator is where that happens, and it only gets installed after the CR
exists), and `IsEnabled` in virt-config checks `FeatureGates` before
`DisabledFeatureGates`, so on a fresh install the same CR is admitted
and the gate silently stays on. Render-time is the only place left where
an operator gets told.

A name repeated inside one list is not an error: upstream compares the
two lists against each other, and both fields are
`x-kubernetes-list-type: atomic` in the CRD, so that CR is accepted and
the guard stays quiet. The gates the chart pins off can arrive a second
time from a supported values file, since the chart writes them itself
and an operator listing the gates their cluster declines has no reason
to know that, so the range skips them and the CR states each opt-out
once. The guard walks its own copy of the seven gates the chart enables.
That copy exists because the rendered list has to stay a literal list
for `make update` to find its `- VMExport` anchor, and a gate quietly
dropped from the copy would keep rendering under `featureGates` while
leaving the guard. The suite carries one case per gate, so removing any
single name turns exactly one of the seven red.

`HotplugVolumes` stays in the list even though 1.9 deprecates it. A
deprecated gate listed in the CR is still enabled, and while it is
enabled virt-controller skips the declarative hotplug path. Dropping it
would switch on declarative hotplug, but then virt-api rejects the
VMI-level `removevolume` subresource on VM-owned VMIs, and kubevirt-csi
uses that as a fallback during teardown. The CSI driver has to move off
that subresource first. Upstream names no removal release for it: the
`Deprecated` state's own doc comment says "discontinued in the following
release", but `MultiArchitecture` and `DisableMDEVConfiguration` have
been deprecated since 1.8.0 and are still registered at 1.9.0, so that
is a direction rather than a date.

What makes that opt-out list matter is a semantics change: on 1.8
`isFeatureGateEnabled` ended in `return false`, so a Beta gate nobody
listed was off; on 1.9 `IsEnabled` ends in `return fg.State == Beta`.
Sixteen gates are Beta at v1.9.0 and none of them is in this chart's
`featureGates`, so all sixteen arrive on with the bump. Two are switched
back off here, one is switched off below Kubernetes 1.35, and I went
through the rest:

- `Template`: off. Reason above.
- `ExternalNetResourceInjection`: off. With it on, virt-controller stops
calling `multus.NetworkToResource`, so a NAD's
`k8s.v1.cni.cncf.io/resourceName` no longer becomes a resource request
on the launcher pod. That is correct for clusters running a
network-resources-injector; this platform ships none, so a VM on an
SR-IOV NAD would schedule without its device.
- `ImageVolume`: off below Kubernetes 1.35, left alone from 1.35 on.
KubeVirt renders containerDisk images as `VolumeSource.Image` volumes
when the gate is on, and it does not check the host: `dropImageVolumes`
in the apiserver strips every image volume and the mounts referencing it
while Kubernetes' own `ImageVolume` gate is off, which is the default
until 1.35 (`kube_features.go` has it `Default: false` at 1.31 and
1.33). The pod is admitted without the disk and virt-launcher fails
looking for it. The management cluster is supported from 1.33, so on
1.33 and 1.34 the chart keeps the KubeVirt gate off and the
containerDisk sidecar path in use; from 1.35 the gate stands and
`extraFeatureGates` can name it. The apiserver version is a proxy for a
runtime capability, not the capability itself, so a cluster at 1.35 or
newer whose container runtime cannot serve image volumes (the k3s case
in #3190) switches the gate off through `kubevirt.disabledFeatureGates`;
that is what the value is for.
- `Snapshot`: on. `VirtualMachineSnapshot` needed the gate listed on
1.8; snapshot and export were exercised on the test cluster.
- `DeclarativeHotplugVolumes`: on and inert.
`handleDeclarativeVolumeHotplug` returns early while `HotplugVolumes` is
enabled, which this chart still does.
- `GPUsWithDRA`, `HostDevicesWithDRA`: on; each only lets a VMI request
a DRA-provisioned device, and nothing here creates one.
- `WorkloadEncryptionSEV`: on; needs SEV hardware and a VM that asks for
it.
- `PasstBinding`: on; needs a VM using the passt binding.
- `RebootPolicy`: on; adds a field on the VMI domain spec, unset means
the old behaviour.
- `VmiMemoryOverheadReport`: on; fills `status.memory.memoryOverhead`,
reporting only.
- `OptOutRoleAggregation`: on; it enables the `RoleAggregationStrategy`
field, and aggregation stops only for a CR that sets it to `Manual`.
This one does not.
- `KubevirtSeccompProfile`: on; installs the profile, and a workload
uses it only where `seccompConfiguration` says so.
- `NodeRestriction`: on; virt-handler node authorization, needs the
Kubernetes `ServiceAccountTokenPodNodeInfo` gate, GA since 1.32.
- `LibvirtHooksServerAndClient`: on; pre-migration hooks on the target
launcher, and no hooks ship here.
- `PodSecondaryInterfaceNamingUpgrade`: flips on; it adds
`--upgrade-ordinal-ifaces` to virt-launcher and a pre-migration hook
that renames the ordinal secondary interfaces of VMs still carrying
them. The test cluster's migrations exercised that path.

Five of the seven gates the chart enables (`ExpandDisks`,
`LiveMigration`, `AutoResourceLimitsGate`, `GPU`, `VMExport`) reached GA
by 1.9 and are inert: `IsEnabled` returns true for a GA gate whether or
not the CR names it. I left the list as it is; dropping the five is a
follow-up, because it changes what the CR says without changing what the
cluster does and it belongs in its own commit.

QEMU is 10.1.0 on both sides of this jump; the el9 build revision moves
from -10 to -20 and libvirt goes 11.9 to 11.10. A moving build revision
is the thing to check rather than a major:
[kubevirt/kubevirt#16386](https://github.com/kubevirt/kubevirt/issues/16386),
where every existing VM lost live migration, was 1.6.2 to 1.7.0 on
qemu-kvm 9.1.0-19 to 9.1.0-20, one build apart within the same QEMU
version. So I tested it: VMs running on the 1.8.4 launcher live-migrated
onto the 1.9.0 one on a three-node cluster.

`make update` in `kubevirt-operator` used to `rm -rf templates` before
the fetch and took the local PrometheusRule template with it. Now it
only overwrites the file it downloads.

`make update` in `kubevirt` now greps for every line of the new block
before it passes: the range directive, the `disabledFeatureGates:` key,
the three static entries, and the guard header that decides which static
entries render. Every insert in that target is guarded by one directive
it also inserts, so a hand-merge that keeps the directive and drops a
sibling line leaves the guard satisfied and the insert skipped. That
shape covers the directive and nothing else. What makes it worth a grep
per line here is the static entries: they are the only lines those
inserts add that are CR content in their own right rather than a wrapper
around a value, so they render on every install and their absence cannot
surface as a value that stopped taking effect. The CR just goes back to
deploying virt-template and to letting KubeVirt skip NAD resource
injection. The target cannot rebuild a partial block, so it names the
missing line and stops. The payload lines of the other four blocks are
exposed the same way; I checked, and both dropping `- {{ . }}` from the
`extraFeatureGates` range and dropping the `permittedHostDevices:` key
from its `with` render green and lose the operator's values. That is a
wider change than this PR and I left it out.

Two sharp edges I know about and left. `kubevirt.disabledFeatureGates:
[HostDevices]` on a cluster that also has `cozystack.gpu-operator` in
`enabledPackages` makes the bundle forward the same gate into both
lists, and the platform renders fine while the child kubevirt
HelmRelease then stops on the guard: fail-closed, with the gate named,
but diagnosed one level below where it was configured. And the
version-conditional opt-out is evaluated at render time, so a cluster
upgraded from 1.34 to 1.35 keeps `ImageVolume` disabled until something
re-renders the chart; the direction is the safe one, since the gate
stays off and containerDisk keeps the path it had on 1.8.4.

Two things I decided against doing here. The guard's copy of the gate
list is pinned against a name being dropped, not against a name being
added to the rendered list only; the copy exists because `make update`
needs the literal `- VMExport` anchor, so closing the other direction
means changing the self-heal contract. And
`hack/run-kubernetes-block-io_test.bats` still names a
`virt-launcher:v1.8.4` image in a fixture: inert, the test matches on
the container name, and the file is outside this change.

Tested on a three-node Talos v1.13.6 / Kubernetes v1.36.2 cluster with
Flux suspended. The upgrade took about ten minutes. virt-operator had
already deployed virt-template before the CR change landed and removed
it afterwards, CRDs included. Two VMs started on the 1.8.4 launcher, one
DataVolume-backed and one containerDisk-backed, live-migrated to the
1.9.0 launcher. VMDisk plus VMInstance through the apps API boots.
`addvolume` on the VM subresource reaches Ready, `removevolume` on the
VMI subresource is accepted. VirtualMachineSnapshot and
VirtualMachineExport from it reach Ready. Restore from snapshot and PVC
clone failed on that cluster inside the LINSTOR API layer, unrelated to
this change. CDI v1.66.0 from #3920 on top of it: HTTP imports to Block
and Filesystem, blank population and hotplug all work. `helm unittest`
is 26/26 for the kubevirt chart and 142/142 for the platform chart, and
the update idempotency script passes its eleven cases.

### Screenshots

Not a UI change.

### Downstream repositories

Walked the trigger map against the diff. No app added or renamed, no
variant, release asset, `ApplicationDefinition` or tooling contract
touched, and none of the `packages/core/platform/values.yaml` keys the
ansible role sets are in the diff.

One repository is reached. `packages/core/platform/values.yaml` gains a
top-level key, `kubevirt.disabledFeatureGates`, defaulting to the empty
list, and `operations/configuration/platform-package.md` on the website
is a hand-written table of `spec.components.platform.values.*` that
nothing generates. The row is in cozystack/website#678, which lands
after this PR merges.

- [ ] No downstream repository is affected by this change
- [x] [cozystack/website](https://github.com/cozystack/website) -
follow-up: https://github.com/cozystack/website/pull/678
- [ ]
[cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack)
- follow-up:
- [ ]
[cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack)
- follow-up:
- [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up:
- [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up:
- [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) -
follow-up:
- [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) -
follow-up:
- [ ]
[cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server)
- follow-up:
- [ ]
[cozystack/external-apps-example](https://github.com/cozystack/external-apps-example)
- follow-up:
- [ ] [cozystack/examples](https://github.com/cozystack/examples) -
follow-up:

### Release note

```release-note
chore(kubevirt): update KubeVirt to v1.9.0. Beta feature gates are on by default upstream now. The platform keeps `Template` off, which would deploy virt-template, and `ExternalNetResourceInjection`, which would hand `resourceName` injection for NetworkAttachmentDefinitions to an injector the platform does not run. `ImageVolume` is disabled on management clusters below Kubernetes 1.35: containerDisk-backed VMs are rendered with native image volumes when it is on, and an apiserver whose own ImageVolume gate is off, the default before 1.35, drops those volumes silently, leaving the VM without its disk. On 1.35 and newer the gate stands, and that is the first release where containerDisk-backed VMs are rendered with image volumes instead of sidecars; the bundled Talos ships Kubernetes 1.36, so this is the default there. A `kubevirt.disabledFeatureGates` list in the platform values opts out of any other gate a cluster cannot carry.
```
2026-09-05 00:30:05 +04:00

757 lines
40 KiB
YAML
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
sourceRef:
kind: OCIRepository
name: cozystack-platform
namespace: cozy-system
path: /
migrations:
enabled: false
# The image digest is NOT hand-edited alongside targetVersion. The release
# build rebuilds the migrations image from this same source tree (which
# carries migrations/<N> and the etcd-migrate binary) and restamps this pin
# in the same commit via `make image-migrations` (yq --inplace) — so image and
# targetVersion are only consistent at a release tag, not mid-PR. The digest
# below therefore lags targetVersion in-tree by design; run-migrations.sh
# refuses to advance past a migration file missing from the image (exit 1), so
# a stale pin fails loudly rather than silently skipping the etcd adoption.
image: ghcr.io/cozystack/cozystack/platform-migrations:v1.6.0@sha256:6777042e3e9c6bad76e7d96fb64baa115061975f39061cb3ede84e21d0e2213f
targetVersion: 57
# Adopt legacy etcd clusters onto the v1alpha2 operator WITHOUT the mandatory
# pre-adoption safety snapshot (migration 50). Leave false unless migration 50
# has actually refused to proceed and you accept the risk: adoption rewires
# ownership of LIVE etcd storage, and a botched adoption on a tenant
# control-plane etcd is UNRECOVERABLE with no snapshot.
#
# Migration 50 refuses when it cannot resolve, or cannot trust, a snapshot
# destination — backups disabled, an external S3 whose credentials were never
# staged, SeaweedFS not ready at upgrade time, or a bucket it cannot classify.
# Those are individually-supported configurations, so rather than leave such a
# cluster permanently unable to upgrade, this flag lets an operator proceed
# deliberately. Prefer fixing the condition the migration names in its log:
# the migration is idempotent, so re-running after the fix is the safe path,
# and this flag is the last resort when there is nothing to fix.
#
# Reset it to false once the upgrade is through, or the next platform upgrade
# that adds an etcd migration will skip its snapshot too.
etcdAdoptSkipBackup: false
# Bundle deployment configuration
bundles:
system:
enabled: false
variant: "isp-full" # Options: "isp-full", "isp-full-generic", "isp-hosted", "distro-full"
iaas:
enabled: false
# gpu-operator variant selector — applies when cozystack.gpu-operator is
# in bundles.enabledPackages. "default" runs the vfio-pci passthrough
# stack (whole GPU → one VM); "vgpu" runs the vGPU Manager stack. The
# platform mirrors this into the KubeVirt CR: passthrough auto-wires the
# HostDevices feature gate plus a default permittedHostDevices.pciHostDevices
# table covering common NVIDIA datacenter GPUs (vendor 10DE); vgpu
# auto-wires permittedHostDevices.mediatedDevices plus a starter
# mediatedDevicesConfiguration. Operators with additional or non-NVIDIA
# cards extend the defaults via gpu.permittedHostDevices /
# gpu.mediatedDevicesConfiguration / gpu.replaceDefaults below.
gpuOperatorVariant: default
paas:
enabled: false
naas:
enabled: false
disabledPackages: []
enabledPackages: []
# Network configuration
networking:
clusterDomain: "cozy.local"
podCIDR: "10.244.0.0/16"
podGateway: "10.244.0.1"
serviceCIDR: "10.96.0.0/16"
joinCIDR: "100.64.0.0/16"
# KubeOVN master nodes override (optional)
# By default, KubeOVN helm chart uses `lookup` to find control-plane nodes
# by label `node-role.kubernetes.io/control-plane`. On fresh clusters or
# during initial deployment, lookup may return empty results.
# Set this to comma-separated list of master node IPs to override.
kubeovn:
MASTER_NODES: ""
# In-cluster (east-west) transport encryption. Opt-in, OFF by default.
#
# When enabled, pod-to-pod traffic that crosses nodes is encrypted at the
# network layer by the ACTIVE datapath, regardless of whether the workload
# speaks TLS — defense-in-depth for the whole mesh without per-application
# changes. This COMPLEMENTS, and does NOT replace, application-level /
# end-to-end TLS: it never reaches an external client and gives a tenant no
# verifiable endpoint certificate (see the per-app certificate series). Use
# it alongside, not instead of, TLS on exposed endpoints.
#
# The mechanism is datapath-specific (selected by bundles.system.variant):
#
# * kubeovn-cilium (isp-full, the default) and kubeovn-cilium-generic
# (isp-full-generic): KubeOVN owns the datapath; its Geneve overlay is
# encrypted with IPsec (kube-ovn ENABLE_OVN_IPSEC). KubeOVN's own
# controller provisions the IPsec CA and per-node certificates through
# the Kubernetes CSR API — no cert-manager wiring is required. This is
# the path this toggle drives today.
# * cilium / cilium-generic (Cilium owns the datapath): Cilium-native
# WireGuard/IPsec is the right mechanism there, but the platform system
# bundle does not select those variants, so this toggle does not reach
# them yet.
# * cilium-kilo: Kilo already establishes a WireGuard mesh, but only at
# meshGranularity=location — it encrypts CROSS-LOCATION traffic and
# leaves intra-location pod-to-pod in cleartext by design. This toggle
# targets exactly that intra-location gap and composes with Kilo rather
# than conflicting with it.
#
# CAVEATS: encrypting the overlay adds per-packet ESP overhead and lowers
# the effective MTU, so east-west throughput drops and latency rises; the
# cost is highest for high-bandwidth flows. IPsec here protects the
# inter-node overlay tunnels — same-node pod-to-pod traffic never leaves the
# host and is not tunneled or encrypted. Flipping this on an existing
# cluster triggers a rollout of the CNI components. On variants without a
# cozystack-managed encryptable datapath (e.g. isp-hosted / noop) the toggle
# has no effect.
encryption:
enabled: false
# Install the upstream reference CNI plugins (bridge, macvlan, ipvlan, ...)
# into /opt/cni/bin on every node, from the multus image. Multus-backed
# NetworkAttachmentDefinitions delegate to these. Talos puts six binaries in
# that directory -- bridge, firewall, host-local, loopback and portmap from the
# same upstream release, plus flannel from a different repo -- and generic Linux
# gives no guarantee at all, so a bridge-type NAD fails there with
# `failed to find plugin "bridge" in path [/opt/cni/bin]`. A NAD naming one of
# the other ten needs staging on either platform.
#
# On for both variants when unset. Four of the names Talos carries are ones
# staging writes, so it rewrites those with the same upstream version (v1.9.1
# on both sides) and adds the ten it does not carry; loopback is not staged and
# flannel was never part of the reference set. Set it explicitly to decline.
#
# A spelling this chart does not recognise stops the whole platform render, not
# just multus, so a typo here halts reconciliation cluster-wide. That is
# deliberate -- reading an unreadable value as "off" would defeat the opt-out --
# but it is why the accepted spellings are worth getting right first time.
#
# When on, the plugins are written every time the Multus pod is recreated,
# replacing files of the same name. 14 of the upstream reference plugins are
# installed; loopback, dhcp, dummy and tap are left alone. See
# docs/vm-external-vlan.md.
#
# On a running cluster this is set on the `platform` component of the
# `cozystack.cozystack-platform` Package CR, the same path as backupStorage
# (see docs/operations/backup-classes.md). Editing the multus HelmRelease or
# the child Package cozystack.multus directly is reverted by the platform
# reconcile.
# stageCniPlugins: true
# Service publishing and ingress configuration
publishing:
host: "example.org"
ingressName: tenant-root
# Optional namespace of a SEPARATE Gateway / ingressClass that system
# components attach their admin routes to (currently Keycloak) — e.g. one
# bound to a private IP, unreachable from the public internet. Empty means
# admin endpoints share the same ingress as everything else (ingressName).
# The private Gateway itself is NOT created by cozystack; provision it out
# of band, then point this at its namespace to move admin traffic onto it.
ingressNameAdmin: ""
exposedServices:
- api
- dashboard
- vm-exportproxy
- cdi-uploadproxy
apiServerEndpoint: "" # example: "https://api.example.org"
externalIPs: []
# Native loadBalancerClass for the host ingress. When externalIPs is empty the
# host ingress publishes its Service as type: LoadBalancer; set this to the
# loadBalancerClass of the LoadBalancer controller that should handle it. The
# admin provisions the matching address pool / announcer out of band (a MetalLB
# IPAddressPool, a Cilium LB-IPAM pool, a cloud LB, etc.). Empty lets the
# cluster's default LoadBalancer controller claim the Service.
# spec.loadBalancerClass is immutable: on a cluster whose host ingress Service
# already exists as type: LoadBalancer, setting, changing, or clearing this
# value requires recreating that Service once (the chart fails early with the
# exact command).
loadBalancerClass: ""
# Enable PROXY-protocol on the host ingress-nginx and auto-deploy
# ouroboros (system/ouroboros) to fix the resulting hairpin-NAT
# problem (intra-cluster traffic to the cluster's own public hostnames
# arrives at ingress-nginx without the PROXY header it now requires).
# Single cozystack-side switch: flipping this to true configures both
# pieces in one go — ingress-nginx use-proxy-protocol and the
# cozystack.ouroboros Package CR.
#
# TALOS RE-RENDER NOTE (host scope only): the host CoreDNS is a
# Talos-managed Deployment; ouroboros mutates its live Corefile in
# place between BEGIN/END markers. A Talos machine-config push or
# upgrade re-renders the Corefile and overwrites the markers — there
# is a flap window of up to one ouroboros reconcile loop (bounded
# by `controller.resync`, default 10 minutes) until the controller
# re-applies the block. The reconcile loop is ALSO event-driven on
# Ingress/Gateway watches, so on a busy cluster the window often
# closes much sooner — but on a stable production cluster with no
# incidental Ingress/Gateway churn, the upper bound is the resync
# interval. In-cluster DNS for hairpinned hostnames briefly returns
# the upstream LB IP instead of the proxy ClusterIP during that
# window, which fails the same way pre-PR behaviour fails.
# Acceptable, but worth knowing during a Talos roll.
#
# PRECONDITION: the upstream L4 load balancer / WAN edge in front of
# ingress-nginx MUST already be injecting PROXY-protocol v1 headers
# before flipping this flag. Without that, every external request
# arrives at ingress-nginx without the PROXY header, ingress-nginx
# closes the connection, and ALL ingress traffic breaks. cozystack
# cannot configure that upstream LB for you — it lives outside the
# cluster (cloud LB, F5, MetalLB+haproxy, hcloud-cloud-controller,
# etc.). PROXY-protocol frames travel from the upstream LB to
# ingress-nginx (the LB opens a fresh TCP connection to the backend
# and prepends the frame on that connection), not back to the
# client — `nc` from a laptop will never see one. Pick one of:
#
# * tcpdump --interface any 'port 80 or port 443' -A on the node
# hosting ingress-nginx and watch for a leading "PROXY TCP4 ..."
# frame on inbound TCP from the LB BEFORE flipping this flag.
# * make any external HTTP request after the LB-side change but
# before flipping this flag, and watch
# `kubectl --namespace cozy-ingress-nginx logs deploy/ingress-nginx-controller`
# for "client sent invalid proxy protocol header" — that error
# means the LB started injecting PROXY frames but ingress-nginx
# is not yet configured to accept them, which is the transition
# state this flag is meant to resolve.
#
# If neither check shows PROXY frames, fix the upstream LB before
# touching this flag. Leave it false on clusters where PROXY-protocol
# is not yet wired at the upstream LB; ouroboros wastes resources
# when the bug it fixes does not exist.
#
# FAN-OUT NOTE: this flag affects ONLY the host control plane. To
# turn the same hairpin fix on inside a tenant cluster, also set
# `addons.ouroboros.enabled: true` in the per-tenant Kubernetes CR
# (and `addons.ingressNginx.enabled: true` is a hard precondition
# there). The flag does not cascade into tenants on its own.
#
# DISABLE PATH: flipping this back from true to false has TWO
# asymmetric effects. ingress-nginx side: the switch travels through
# _cluster.proxy-protocol in the cozystack-values Secret, so the next
# reconcile re-renders the host ingress-nginx (extra/ingress) without
# the use-proxy-protocol / real-ip-header / enable-real-ip keys
# (cozystack deliberately never sets use-forwarded-headers or
# compute-full-forwarded-for — those would allow any upstream proxy
# to spoof X-Forwarded-For without a paired proxy-real-ip-cidr — see
# the rationale in extra/ingress/templates/nginx-ingress.yaml). The
# cozystack.ingress-application Package stays the bare default
# throughout; the keys never ride on it. ingress-nginx then stops
# accepting PROXY-protocol headers. If the upstream L4 LB is
# still prepending PROXY frames at that moment, every external
# request to ingress-nginx breaks until the LB is also reconfigured
# — flip the LB OFF FIRST, then flip this flag. ouroboros side:
# stops emitting the cozystack.ouroboros Package CR, but every Package
# CR carries `helm.sh/resource-policy: keep`, so Helm leaves the
# existing Package on the cluster, ouroboros stays installed, and
# the live Corefile rewrite block keeps pointing at the still-running
# ouroboros-proxy Service. Flag-flip alone leaves ouroboros idempotent.
#
# To actually uninstall ouroboros, the operator removes the Package
# CR explicitly:
#
# kubectl delete package.cozystack.io cozystack.ouroboros
#
# or adds the package name to bundles.disabledPackages. THAT is the
# path that triggers the chart's pre-delete Helm hook
# (charts/ouroboros/templates/coredns-cleanup-hook.yaml, vendored at
# 0.8.0) — the hook quiesces the controller, sed-strips the
# BEGIN/END block from the live kube-system/coredns Corefile, and
# restores the cleaned ConfigMap via kubectl replace. The hook is
# automatic; operators do NOT need to run a manual sed recipe in
# the normal disable path. Documentation of the hook's exact
# behaviour lives in the upstream chart's README.
#
# Manual cleanup recipe (only if the chart's pre-delete hook fails
# to land — controller pod stuck in CrashLoop blocking the quiesce
# step, ConfigMap RBAC drift on the namespace, helm uninstall
# interrupted before the hook ran). Uses a JSON merge-patch so
# labels, annotations, and other data keys on the ConfigMap —
# including any Talos-managed metadata — are preserved:
#
# # === BEGIN cleanup-recipe ===
# existing=$(kubectl --namespace kube-system get configmap coredns \
# --output jsonpath='{.data.Corefile}')
# cleaned=$(printf '%s\n' "$existing" \
# | sed '/# === BEGIN ouroboros/,/# === END ouroboros ===/d')
# kubectl --namespace kube-system patch configmap coredns \
# --type merge \
# --patch "$(jq --null-input --arg c "$cleaned" \
# '{data: {Corefile: $c}}')"
# kubectl --namespace kube-system rollout restart deployment/coredns
# # === END cleanup-recipe ===
proxyProtocol: false
# Acknowledgement gate for the helm.sh/resource-policy: keep
# asymmetry (NOT a substitute for the chart's pre-delete cleanup
# hook — the hook handles the Corefile patch automatically when
# the chart actually uninstalls). The hazard this gate catches:
# flipping publishing.proxyProtocol from true to false stops
# emitting the cozystack.ouroboros Package CR, but resource-policy:
# keep means Helm leaves the existing Package on the cluster.
# ouroboros keeps running, the cleanup hook never fires, the
# rewrite block stays live. The platform render fails until the
# operator either restores proxyProtocol: true OR runs `kubectl
# delete package.cozystack.io cozystack.ouroboros` (which lets
# the chart actually uninstall and the hook run) and sets this
# flag to true to confirm. Once the cluster has been clean for
# one reconcile cycle, flip back to false.
#
# KNOWN HOLE: the guard keys off a `lookup` for the cozystack.ouroboros
# Package CR on the cluster. An operator who manually
# `kubectl delete package cozystack.ouroboros` before flipping the
# flag back bypasses the check entirely (the lookup returns nil, the
# render proceeds). In the chart 0.8.0 that path is mostly safe —
# `kubectl delete package` triggers helm uninstall and the chart's
# pre-delete hook patches the Corefile automatically. The hole is
# the rare case where the hook itself fails (controller pod stuck,
# ConfigMap RBAC drift, hook timeout) and the operator never
# noticed. The values comment + the acknowledge gate are
# defence-in-depth, not an airtight lock; an operator deliberately
# working around them gets to keep the broken pieces.
proxyProtocolAcknowledgeUnclean: false
certificates:
solver: http01 # "http01" or "dns01"
issuerName: letsencrypt-prod
# Shared wildcard issuance on the default ingress-nginx path
# (gateway.enabled=false). Opt-in, OFF by default. When set to true
# with solver=dns01 and no operator-provided wildcardSecretName, the
# platform issues ONE wildcard Certificate (*.<root-host> +
# <root-host>) via the DNS-01 ClusterIssuer and serves it as the
# ingress controller's default SSL certificate, so system services
# (dashboard, grafana, keycloak, harbor, …) stop minting a per-host
# ACME cert each. This avoids the Let's Encrypt per-domain rate limit
# once a deployment exceeds ~50 endpoints, matching the Gateway API
# path which issues a per-apex wildcard in dns01 mode.
#
# Ignored when solver=http01 (HTTP-01 cannot issue wildcards) and
# when gateway.enabled=true (the TenantGateway controller issues the
# wildcard there).
#
# COVERAGE CAVEAT — same contract as wildcardSecretName below: a
# single-label wildcard *.<root-host> covers <service>.<root-host>
# but NOT a custom service host outside it (e.g. a keycloak
# ingress.host / harbor host / grafana host set to auth.example.com,
# or a nested a.b.<root-host>). When this is true, services whose
# host is not covered fall back to the default SSL certificate and
# would serve the wrong certificate. Only enable it when every
# exposed system service uses a <service>.<root-host> host (the
# default), or provide a covering wildcardSecretName instead. Left
# OFF by default precisely so a dns01 cluster with a custom service
# host is never silently switched on upgrade.
#
# BLAST RADIUS — like wildcardSecretName, the chosen name rides the
# _cluster channel, which every child tenant inherits verbatim. A
# child tenant that inherits the root ingress has nested service
# hosts (<service>.<tenant>.<root-host>) that *.<root-host> does NOT
# cover; enabling this makes those services drop per-host ACME and
# serve the root default certificate too. This is not root-tenant
# scoped — only enable it when child-tenant hosts are also covered
# (or left on the Gateway path). Per-tenant wildcards are tracked
# separately.
#
# FIRST-ISSUANCE WINDOW: when this is turned on, consumers drop their
# per-host certs immediately, but the DNS-01 wildcard takes a few
# minutes to issue. Until the Secret is populated ingress-nginx serves
# its self-signed default cert (browser warning), then self-heals —
# the same delay per-host ACME has on first issue, which an
# operator-provided wildcardSecretName avoids only by pre-existing.
wildcard: false
# Operator-provided wildcard certificate. When set, platform
# services and the root tenant's ingress/Gateway serve under this
# pre-existing TLS Secret instead of minting per-host ACME certs.
# The Secret must already exist in the publishing namespace — the
# one that runs the root ingress controller / Gateway, which follows
# publishing.ingressName (tenant-root by default) — be of type
# kubernetes.io/tls, and cover the root host (typically a wildcard
# *.<root-host> + <root-host>). Only the
# NAME is distributed through the platform values channel — the
# cert/key material is never broadcast. Leave empty to keep ACME
# issuance (solver/issuerName above).
#
# Child tenants are covered automatically: the platform controller
# replicates this Secret into every tenant namespace that runs its own
# ingress controller, and into Gateway owners as long as their Gateway
# terminates TLS itself (see gateway.edgeTerminatedClasses below), so each
# per-tenant termination point serves the wildcard from its own
# namespace (no cross-namespace Secret
# read, no widened tenant RBAC). No extra input — the same name set
# here drives both the consumers and the replication. The replica
# carries the wildcard private key into each terminating tenant
# namespace (the same exposure as the per-host ACME Secret it replaces,
# now shared across tenants), and covers a child apex only if the
# certificate's SAN list does — a single *.<root-host> does not match
# *.<child-apex>, so supply SANs covering the child apexes you serve.
# On a freshly-created tenant the replica may land a moment after the
# tenant's ingress controller starts. The window is bounded: the
# platform controller creates the replica within one reconcile, and
# ingress-nginx watches its default-ssl-certificate Secret and adopts
# it when it appears (no restart needed). Until then ingress-nginx logs
# a warning and serves its built-in certificate.
wildcardSecretName: ""
# Rate-limit note: every tenant with gateway=true issues one
# Certificate for its wildcard + apex hostnames. If many tenants share
# the same apex domain with issuerName=letsencrypt-prod, the cluster
# can hit the Let's Encrypt limits (50 certs / registered domain /
# week, 5 duplicate certs / week, 300 new orders / account / 3h).
# Use letsencrypt-stage for non-production clusters or gate the
# number of certificates per tenant via tenant.spec.resourceQuotas
# with count/certificates.cert-manager.io. See
# https://letsencrypt.org/docs/rate-limits/.
#
# DNS-01 solver configuration. Read only when solver=dns01. The
# provider key selects which sub-block is consumed; others are
# ignored. Cloudflare keeps backwards-compatible defaults so the
# most common opt-in path (cloudflare token + dns01) needs only
# solver=dns01 + dns01.cloudflare.secretName.
dns01:
provider: cloudflare # cloudflare | route53 | digitalocean | rfc2136
cloudflare:
secretName: cloudflare-api-token-secret
secretKey: api-token
route53:
region: ""
accessKeyID: ""
secretName: ""
secretKey: secret-access-key
digitalocean:
secretName: digitalocean-api-token-secret
secretKey: access-token
rfc2136:
nameserver: ""
tsigKeyName: ""
tsigAlgorithm: HMACSHA256
secretName: ""
secretKey: tsig-secret-key
# Telemetry reported by platform components.
#
# Two components report: cozystack-operator (cluster facts — nodes, storage,
# packages) and cozystack-controller (application counts). This key covers the
# CONTROLLER, which the platform deploys. The operator is deployed by the
# cozy-installer chart and is switched off separately, with
# cozystackOperator.disableTelemetry=true — a full opt-out needs both, because
# the two components are installed by two different charts.
#
# What is collected, and why, is documented at
# https://cozystack.io/docs/operations/configuration/telemetry/
telemetry:
disabled: false
# Authentication configuration
authentication:
oidc:
enabled: false
insecureSkipVerify: false
keycloakExtraRedirectUri: ""
# In-cluster URL of the KeyCloak realm, used for backend-to-backend requests. oauth2-proxy runs
# with --skip-oidc-discovery and sends every backend call (token, jwks, userinfo, logout) to this
# URL, while browser-facing redirects keep pointing at the external host.
#
# This is the default path: the bundled KeyCloak is the only supported provider, so those calls
# have no reason to leave the cluster. Taking the external hostname instead would route them
# through public DNS and the root ingress — which does not serve yet on a fresh install, leaving
# the dashboard permanently down.
#
# The keycloak-http Service has no TLS listener, so these backend calls travel as plaintext HTTP
# between pods, as keycloak-configure's own admin calls to the same address already do.
#
# Override only for a KeyCloak that does not live at the standard in-cluster address. Setting it
# to an empty string restores full OIDC discovery against the external issuer.
keycloakInternalUrl: "http://keycloak-http.cozy-keycloak.svc:8080/realms/cozy"
# Gateway API configuration
gateway:
# Enable Gateway API support across the platform. When true:
# - cert-manager ClusterIssuers use an http01.gatewayHTTPRoute solver
# that attaches to the root tenant's Gateway, so Certificate issuance
# works for tenants whose ingress is via Gateway API rather than
# ingress-nginx.
# - Exposed services (dashboard, keycloak, harbor, bucket, grafana,
# cozystack-api, vm-exportproxy, cdi-uploadproxy) render an
# HTTPRoute attached to the tenant's Gateway.
# Per-tenant opt-in is still governed by tenant.spec.gateway=true, which
# materialises the Gateway itself. This flag only controls platform-wide
# Gateway API integration (cert-manager solver + per-service HTTPRoutes).
enabled: false
# Default GatewayClass for tenant Gateways. A tenant picks another one
# with `gatewayClass` on its Tenant resource; this is the value used when
# it does not. The default is the Cilium class the platform ships. Reaches
# the per-tenant gateway chart as _cluster.gateway-class-name.
className: cilium
# GatewayClasses whose provider terminates TLS upstream of the Gateway
# (a Cloudflare Tunnel class ends TLS at the Cloudflare edge and reaches
# the Gateway over the tunnel). TLS termination is a property of the
# class, not of the tenant, so it is declared here once and every tenant
# that selects such a class gets it: the TenantGateway controller then
# issues no certificates for that Gateway, renders plain HTTP listeners
# for the apex and its wildcards, and skips the TLS-passthrough listeners
# — which leaves the tenant Kubernetes API, VM export and CDI upload
# endpoints unpublished through it, their TLSRoutes matching no listener.
#
# Listing a class here is a claim about that class and nothing validates
# it: name the bundled `cilium` and its Gateways publish every app
# hostname over plain HTTP on a public address, with no redirect and no
# certificate. Only list a class whose provider really does terminate TLS
# in front of the Gateway.
#
# Moving an existing tenant onto such a class also withdraws the operator
# wildcard from it: its namespace stops counting as a TLS termination
# point, so the replica of publishing.certificates.wildcardSecretName is
# deleted from it on the next reconcile. Ingress owners keep theirs, and a
# missing source Secret postpones the deletion rather than forcing it.
# Reaches the per-tenant gateway chart as _cluster.gateway-edge-classes.
edgeTerminatedClasses: []
# GatewayClasses a tenant may select for its own Gateway through
# `tenant.spec.gatewayClass`, on top of className above (which every
# tenant may always end up on, since it is the default). A tenant asking
# for anything outside this set fails its own gateway release with a
# message naming the class, and reaches no other tenant.
#
# This is an allowlist because Tenant is a tenant-writable object and a
# GatewayClass is cluster-scoped: without it a tenant could attach its
# Gateway to any class the cluster registers, including one an admin
# keeps for internal-only or differently-fronted traffic. Empty (the
# default) means tenants cannot choose at all and every Gateway lands on
# className. The allowed set is this list plus the CURRENT className, so
# changing className while a tenant pins the previous one by name fails
# that tenant's gateway release until it is updated too — list the old
# class here when moving the default. Reaches the per-tenant gateway
# chart as _cluster.gateway-tenant-classes.
tenantSelectableClasses: []
# Advertise HTTP/2 on every Gateway API listener served by the bundled
# Cilium dataplane. Browsers negotiate HTTP/2 exclusively through TLS ALPN
# "h2"; with this off, Envoy advertises no ALPN protocols and every client
# silently falls back to HTTP/1.1 — no error anywhere, just head-of-line
# blocking and the per-origin connection limit that HTTP/2 removes.
# ingress-nginx (which the Gateway path replaces) advertised h2 out of the
# box, so on-by-default restores the pre-migration behaviour. ALPN offers
# h2 then http/1.1, so clients without HTTP/2 keep working unchanged.
#
# Frontend hop only: gateway↔backend connections stay HTTP/1.1 unless a
# Service opts in per GEP-1911 by declaring appProtocol
# kubernetes.io/h2c on its port (that backend-protocol support is switched
# on together with ALPN; no cozystack-shipped Service declares such a
# value today, so backends see no change from this flag alone).
#
# Cluster-wide: maps to Cilium's enable-gateway-api-alpn agent config, so
# it covers the root and every tenant Gateway at once — there is no
# per-Gateway granularity in the dataplane. Only effective on bundles
# where cozystack manages Cilium (isp-full, isp-full-generic); on
# isp-hosted the hosting-side CNI owns this setting. Flipping it re-rolls
# the cilium DaemonSet on the next platform upgrade (rollOutCiliumPods),
# the same disruption profile as any cilium config change.
http2: true
# Namespaces that are allowed to attach HTTPRoute or TLSRoute to a tenant
# Gateway. The publishing tenant namespace is always included implicitly.
# Additional entries must be the exact namespace name (matched on the
# built-in kubernetes.io/metadata.name label). Tenants not on this list
# cannot attach a route to somebody else's Gateway, which prevents
# hostname hijacking across tenants.
#
# The `default` namespace is included because the Kubernetes API's
# TLSRoute (shipped by the cozystack-api package) has to live next to
# the `kubernetes` Service it points at, which is always in `default`.
attachedNamespaces:
- cozy-cert-manager
- cozy-dashboard
- cozy-keycloak
- cozy-system
- cozy-harbor
- cozy-bucket
- cozy-kubevirt
- cozy-kubevirt-cdi
- cozy-monitoring
- cozy-linstor-gui
- default
# Platform monitoring configuration.
monitoring:
# Whether the root tenant (tenant-root) hosts the platform
# VictoriaMetrics/VictoriaLogs stack, i.e. Tenant/root spec.monitoring=true.
# The platform centralises metrics and logs in tenant-root, and
# cozystack-basics publishes vlinsert-generic / vminsert-* ExternalName
# Services in cozy-monitoring that redirect there. When the root tenant has
# monitoring disabled those redirects dead-end and fluent-bit silently drops
# logs (issue #3181), so the ExternalNames are only created when this is
# true. This is the single render-time source of truth for that gate:
# changing it re-renders cozystack-basics (helm-controller watches the
# cozystack-values Secret it flows into). Nothing in the charts sets
# Tenant/root spec.monitoring — it is a runtime choice on the Tenant CR
# (default false; the standard install enables it out-of-band). The default
# here is true only to preserve the historical always-create behaviour;
# operators MUST set it to match their actual Tenant/root spec.monitoring.
rootEnabled: true
# Backup storage overrides for the platform-managed cozy-default BackupClass.
# Everything set here is forwarded verbatim into the emitted
# cozystack.backupstrategy-controller Package CR as
# components.backupstrategy-controller.values.backupStorage, so it lands on the
# backupstrategy-controller HelmRelease and deep-merges over that chart's own
# backupStorage defaults (packages/system/backupstrategy-controller/values.yaml
# documents every knob: provisionBucket, bucketName, endpoint, region,
# forcePathStyle, systemSecretName, systemNamespaces, …). Admins set this via
# spec.components.platform.values.backupStorage on the
# cozystack.cozystack-platform Package — see docs/operations/backup-classes.md.
# Empty (the default) forwards nothing and keeps the child chart defaults.
backupStorage: {}
# Pod scheduling configuration
scheduling:
globalAppTopologySpreadConstraints: ""
# UI branding configuration. The whole map is propagated verbatim into
# _cluster.branding (the cozystack-values Secret) and consumed by the dashboard
# (config.json) and Keycloak realm provisioning.
#
# Recognized keys:
# brandName: realm displayName (the Keycloak login title reads it as
# "Sign in to <brandName>").
# brandHtmlName: realm displayNameHtml (HTML shown in the login header).
# loginTheme: Keycloak login theme name; selected as the realm login
# theme and used as the theme directory/name.
# loginThemeImage: OCI image carrying that theme under /themes/. When set
# together with loginTheme, the keycloak chart mounts it via
# an init container, so the theme ships without patching the
# StatefulSet or the keycloak package values.
#
# Example:
# branding:
# brandName: "Acme Platform"
# brandHtmlName: "<b>Acme</b> Platform"
# loginTheme: acme
# loginThemeImage: registry.example.com/acme-keycloak-theme:v1
branding: {}
# Container registry mirrors configuration
#
# Example:
# registries:
# mirrors:
# docker.io:
# endpoints:
# - http://10.0.0.1:8082
# ghcr.io:
# endpoints:
# - http://10.0.0.1:8083
# gcr.io:
# endpoints:
# - http://10.0.0.1:8084
# registry.k8s.io:
# endpoints:
# - http://10.0.0.1:8085
# quay.io:
# endpoints:
# - http://10.0.0.1:8086
# cr.fluentbit.io:
# endpoints:
# - http://10.0.0.1:8087
# docker-registry3.mariadb.com:
# endpoints:
# - http://10.0.0.1:8088
# config:
# "10.0.0.1:8082":
# tls:
# insecureSkipVerify: true
registries: {}
# Resource allocation ratios
resources:
cpuAllocationRatio: 10
memoryAllocationRatio: 1
ephemeralStorageAllocationRatio: 40
# KubeVirt CR settings that no other platform knob implies. Forwarded into the
# emitted cozystack.kubevirt Package CR as components.kubevirt.values, next to
# the entries the iaas bundle derives from resources.cpuAllocationRatio and
# from the gpu block below.
kubevirt:
# Feature gates switched off under
# spec.configuration.developerConfiguration.disabledFeatureGates, on top of
# the opt-outs the kubevirt chart pins: Template and
# ExternalNetResourceInjection always, ImageVolume below Kubernetes 1.35.
# KubeVirt 1.9 turns every Beta gate on by default, so this is how a cluster
# declines one it cannot carry — a container runtime without image volume
# support on Kubernetes 1.35 or newer is the case this list is for.
#
# kubevirt:
# disabledFeatureGates:
# - ImageVolume
#
# A gate the chart already enables cannot be switched off here. KubeVirt
# refuses a CR that names one gate in both lists, so the chart stops the
# render and names the gate rather than ship a CR the cluster would reject
# on update and misread on install.
disabledFeatureGates: []
# GPU host-device wiring for VirtualMachine workloads. Auto-injected into the
# KubeVirt CR's permittedHostDevices when bundles.enabledPackages contains
# cozystack.gpu-operator. Without it the admission webhook rejects any VM
# that references a GPU host-device by resourceName.
gpu:
# When false (default), the lists below are appended to the platform's
# NVIDIA defaults. When true, the user lists fully replace the defaults
# — use this for clusters with only non-NVIDIA accelerators or where a
# strictly curated allowlist is required.
replaceDefaults: false
permittedHostDevices:
# PCI passthrough devices. Always rendered when non-empty regardless of
# gpuOperatorVariant — pciHostDevices covers both the vfio-pci passthrough
# path (default variant) and the post-kubevirt#16890 SR-IOV vGPU path
# (vgpu variant on Ada Lovelace / Blackwell, where VFs are advertised
# via pciHostDevices, not via mediatedDevices). Default-table coverage:
# H100, H200, A100 PCIe/SXM, A40, A30, A10, L40, L40S, L4, T4, V100,
# V100S (PCI vendor 10DE). Item shape matches KubeVirt's pciHostDevices:
# - pciVendorSelector: "10DE:2335"
# resourceName: nvidia.com/GH100_H200_SXM_141GB
# externalResourceProvider: true
pciHostDevices: []
# Mediated (mdev) vGPU devices — pre-kubevirt#16890 path used by
# Pascal–Ampere on the legacy mdev driver branch. Default-table coverage:
# A100-40C/80C, A40-24Q/48Q, A30-24C, A10-24Q, V100D-32C, T4-16Q.
# Item shape matches KubeVirt's mediatedDevices:
# - mdevNameSelector: NVIDIA A100-40C
# resourceName: nvidia.com/A100-40C
# externalResourceProvider: true
mediatedDevices: []
# mediatedDevicesConfiguration makes KubeVirt itself create mdevs on the
# node (vgpu variant only). The platform ships NO default here: mdev
# creation is delegated to the GPU Operator's vGPU Device Manager
# (name-based), and the mediatedDeviceTypes ids below are numeric
# nvidia-NNN sysfs indices that vary per GPU SKU and driver branch — no
# value is portable, so look yours up on the host
# (/sys/bus/pci/devices/<BDF>/mdev_supported_types/*/name) before setting
# it. Supplying it opts into KubeVirt-driven creation on top of the
# Device Manager. Helm's mergeOverwrite semantics apply: a top-level key
# you supply REPLACES that key wholesale rather than appending. Shape
# matches KubeVirt's MediatedDevicesConfiguration:
# mediatedDeviceTypes:
# - nvidia-740
# nodeMediatedDeviceTypes:
# - nodeSelector:
# nvidia.com/gpu.product: NVIDIA-L40S
# mediatedDeviceTypes:
# - nvidia-740
mediatedDevicesConfiguration: {}
# NVIDIA vGPU Manager container image (vgpu variant only). The .run is
# proprietary, not redistributable, so the platform cannot ship default
# tags — the operator builds the container per
# https://github.com/NVIDIA/gpu-driver-container and supplies the
# private-registry coordinates here. The platform forwards these as
# components.gpu-operator.values.gpu-operator.vgpuManager to the emitted
# cozystack.gpu-operator Package CR when bundles.iaas.gpuOperatorVariant
# is vgpu. Forwarding triggers when ANY of repository, version, image
# (non-default), or imagePullSecrets is set — partial values still
# propagate so a private-registry-with-default-tag setup is not
# silently dropped.
vgpuManager:
repository: ""
image: vgpu-manager
version: ""
imagePullSecrets: []
# vGPU Device Manager controls whether nvidia.com's
# `vgpu-device-manager` DaemonSet is deployed (vgpu variant only). The
# DaemonSet walks /sys/class/mdev_bus/ to auto-create mediated devices
# from the mediatedDeviceTypes list. Default-off because that path
# only exists on Pascal–Ampere (V100, T4, A100, A30, …) with the mdev
# driver branch — on Ada Lovelace / Blackwell (L4, L40, L40S, B100)
# with the vGPU 17/20 driver branch the directory is missing and the
# DaemonSet crash-loops with "no parent devices found". Flip to true
# on Pascal–Ampere clusters; leave false on Ada/Blackwell and supply
# SR-IOV VFs via .gpu.permittedHostDevices.pciHostDevices instead.
# When true the platform also lets the default name-based mediatedDevices
# exposure list from files/gpu-vgpu-defaults.yaml flow into the KubeVirt
# CR; when false those defaults are suppressed (advertising mediated
# resources that nothing can ever allocate is a worse footgun than
# missing entries).
vgpuDeviceManager:
enabled: false