Review a recorded configuration for nvidia/gpu-operator@v26.7.1. Read its exact Kubernetes objects, required setup, and current evidence before you deploy it.
The first recorded configuration is default. Read its status before use; it is not yet a polished public example. The page does not claim every possible values combination.
Evidence labels: Pass has a linked result. Watch names a limit to check. Blocked means do not use that path yet.
Upstream: the Catalog fetched chart gpu-operator from the Helm repository https://helm.ngc.nvidia.com/nvidia at version v26.7.1. find this chart on Artifact Hub · Helm documentation. This page adds checked configurations and test results.
Guides.See what a gpu-operator upgrade changes, from one version to the next and for a driver change alone. It says which changed fields can restart pods on GPU nodes, and how a version step moves through dev and QA. Make a stack from Catalog entries shows how to combine this chart with others and check them together.
What it is.nvidia/gpu-operator v26.7.1, as 27 Kubernetes objects in its default preset. The Catalog holds 7 presets of this version.
Every chart page follows the same order. Choose a configuration, inspect its objects and setup work, then read the tests that have run. Open the worked examples.
The page names the work and says which delivery path has actually run.
What To Use
default configuration: 27 rendered objects · 41 images · 8 target prerequisites · 0 hook or setup steps · 1/1 checks passing. These counts come from the linked test records.
defaultFirst recorded base variant
7Candidate base variants
Review before useFirst-configuration status
Not reviewed for productionProduction status
The chart needs manual review before a user-facing recommendation is made.
No specific missing capability is recorded. The first configuration still needs review.
Namespace
gpu-operator
Four Separate Questions
Inspecting a source, producing objects, checking a destination, and checking a live result are different jobs. A Catalog match is useful for comparison but is not required. A missing destination or deployment is shown as not run or blocked, not as a failed configuration.
Question
Current answer
What it needs
Status
What do I have?
Inspect the helm source, choices, locks, and any existing output before selecting a destination.
Destination access: no Selected configuration deployed: no
Available to inspect evidence recorded
What will it produce?
Run the recorded Helm render step to produce the exact Kubernetes objects for this configuration.
Destination access: no Selected configuration deployed: no
Checked: passed evidence recorded
Can this destination accept it?
The destination has not been checked for this exact configuration. A recorded source or render result is not a destination pass.
Destination access: yes Selected configuration deployed: no
Not run no run recorded
Did it work?
No post-deployment result is recorded for this exact configuration. Publication, upload, or rendering is not proof that it ran correctly.
None in the catalog base. Later edits appear in ConfigHub Unit revision history or a derived variant.
8 prerequisites recorded.
Upgrade rule: if a new Helm render and a ConfigHub revision both change the same field, review the overlap before promotion. The values profile shows the Helm side; Unit revision history shows the ConfigHub side.
Shipping a chart as plain rendered YAML is faster and simpler, and it silently drops anything Helm was going to do afterwards. This section reports what a scan of the packaged chart found, across 53 files.
Construct
Found
Why it matters when a chart ships as plain YAML
Helm hooks
10
Hook Jobs never fire, or fire under a different hook dialect.
Keep policy
2
A reconciler prunes what Helm promised to keep.
Capability branching
1
The chart chooses apiVersions from the cluster it renders against.
Custom resource definitions
9
Per-file delivery can race the definitions the resources depend on.
Condition-gated subcharts
1
What renders depends on which conditions the values switch on.
A flattening-safety verdict has decided this version: aicr-eks-training:flatten-with-routes; default:flatten-with-routes; driver-580.105.08:flatten-with-routes; driver-580.126.20:flatten-with-routes; external-nfd:flatten-with-routes; preinstalled-driver-and-toolkit:flatten-with-routes; preinstalled-driver:flatten-with-routes. The verdict records one disposition per construct and names any companion artifact a flattened bundle must ship. What the flattening verdict means.
A construct being present does not make a chart unflattenable. Most are switched on or off by values, and a verdict records which ones the base you choose actually reaches. Read the catalog-wide evidence for how common each one is.
What The Starting Configuration Records
A base variant is a starting configuration we have already rendered and checked. Pick the one whose trade-off you want; the table below shows what each one changes. How the values for each are chosen.
The default base-variant record connects those Helm inputs to the Kubernetes objects, remaining requirements, hooks, CRDs, checks, and OCI status. Open it when you need the complete starting record rather than only the rendered YAML.
Open the full rendered YAML to read the actual manifest output. The render record and setup section explain the inputs, tests, CRDs, hooks, and other work around it.
If new Helm values create a useful starting configuration, record another base variant with its own inputs and checks. If one environment changes a field after rendering, record that change in a ConfigHub variant.
The exact installer package for this chart version. The version tag is readable, and the manifest digest makes a published pull immutable. Public catalog package refs are published in Google Artifact Registry with anonymous read access. No ConfigHub account or Google registry login is needed for the local setup path.
Required before apply
8 CRDs Included in the OCI package as prerequisites/target-facts/default-crds.yaml. It applies missing CRDs server-side. The generated try script leaves existing CRDs under their current owner and waits for them before the workload.
External resources the recommended base variant expects, such as an existing Secret, namespace, CRD, or target fact.
Instructions and decisions for hooks, CRDs, generated Secrets, setup jobs, cluster requirements, or blockers.
Choose base variant
Pick the supported Helm configuration for this chart: default, no-CRDs, existing Secret, HA, server-only, or another listed option.
Record inputs
Keep the values, namespace, release name, source lock, default render intent, full YAML output, package base, test results, and setup instructions together.
Handle chart extras
CRDs, hooks, setup jobs, external Secrets, target facts, and webhook certificates are recorded as chart-specific choices. Some are included in a base variant, some need a setup step, and some are blocked until there is a safe path.
Review default before use. If a card says review or preparation is needed, treat that as a real limit rather than a ready install.
Package image
Exact package:oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v26.7.1@sha256:03fa8aec9221b64cc5c25f3334775338a9f98c0529bad66f12340d124c238b71 publication receipt recorded · open the exact publication receipt
Readable version tag: oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v26.7.1. The package is pinned so a republished tag cannot change what you get. The command below uses the exact manifest digest, so cub installer refuses different package bytes.
cub installer pull 'oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v26.7.1@sha256:03fa8aec9221b64cc5c25f3334775338a9f98c0529bad66f12340d124c238b71' --work-dir ./package-review
less ./package-review/package/records/README.md
The package's records/ directory connects every base to its source choices, Helm render intent, Kubernetes objects, prerequisites, lifecycle work, and checks. These are supporting records, not Kubernetes objects.
Verify the package publisher
Run this command with cosign. It checks the expected publisher, the exact manifest digest, and the package annotations.
A valid signature identifies who signed these package bytes. It does not show that the configuration is suitable for your cluster; use this page's checks and setup instructions for that decision.
Public catalog package refs are published in Google Artifact Registry with anonymous read access. No ConfigHub account or Google registry login is needed for the local setup path.
Run the whole sequence as one script, prerequisites included: try.sh renders and applies to Kubernetes without an account; confighub.sh renders and uploads to your ConfigHub Space.
Before you run try.sh: it changes your current kubectl context. It runs the named prerequisites and applies the rendered objects. Read it first and use a disposable test cluster. confighub.sh does not apply anything to Kubernetes.
You should see something like this
Here is what the command does. cub installer is an open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally, leaving delivery to kubectl, Argo CD or Flux. The generated scripts stop before doing any work when the plugin or kustomize is missing.
cub installer setup ...
rendered manifests written under <work-dir>
use the chart option cards below to check pass, watch, blocked, and prerequisites
Current status: Available in the catalog · Reason: Promotion needs source and destination ConfigHub Spaces. It has not been tested for this configuration.
Use this entry in ConfigHub
Every Catalog entry page carries these five steps in this order. Each step says what the Catalog has run for this entry, and a step with a missing precondition gives no command.
Steps 1 and 2 need no account. Install the cub CLI before any cub command. Step 2 uses cub config diff, which cub plugin install confighub/cub-workshop@v0.6.61 adds. This page covers 7 entries, so open the one you want. A live walk on 2026-10-08 ran steps 3 to 5 for bitnami-nginx-24-0-2-http-clusterip and nvidia-gpu-operator-v26-3-3-default. These commands carry the changes that walk needed. It is a dated log and no receipt, so no state on this page rests on it.
Helm chart, base default, version v26.7.1What is fixed, and what you supply
Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.
chart is nvidia/gpu-operator
version is v26.7.1
base is default
valuesProfile is recipes/nvidia/gpu-operator/v26.7.1/effective-values.yaml
namespace is gpu-operator
releaseName is gpu-operator
capabilityProfile is {"apiVersions":[],"kubeVersion":"1.31.0"}
Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.
gpu-operator CRD included in this base; it must be established before Kubernetes accepts the rendered ClusterPolicy object Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
This entry's plan, and how to test it
These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.
When you deliver. Apply the 8 CustomResourceDefinition objects first. Wait until every named definition reports the Established condition. The listing gives the rest. Who: whatever applies the objects. Written down. Not run by the Catalog.
Around an upgrade. Before an upgrade, move the CRDs to the new version. Helm does not upgrade CRDs from a chart's crds directory, so the chart ships this Job. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. Before deleting, remove a chart-managed GPUCluster and wait for it to go. The Job deletes the chart-managed GPUCluster object and waits until it is gone, so the operator can drain workloads under its finalizer while it is still running. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. After deleting, prune node-feature-discovery labels from the nodes. The Job runs nfd-master -prune, which removes node-feature-discovery labels, annotations and taints from every node, with its own ServiceAccount, ClusterRole and ClusterRoleBinding. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Test the install steps yourself.This script carries them out with kubectl on a cluster you choose, with no account. Read it first and use a throwaway cluster. The Catalog ran it on a local cluster, and the log has every line.
Test the plain objects.A second script tests the retained objects themselves with kubectl, and it needs no cub and no account. The Catalog has no recorded run of this script.
Upgrade and delete. The Catalog carried out this entry's upgrade and delete steps by hand on a local cluster, and the log has every line.
The Catalog rendered this entry and retains its 27 objects in one file.
An upload can create more Units than the objects counted here. The installer renders a Namespace, and the upload adds an installer-record Unit.
# fetch the retained objects for this entry$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/default/r001/rendered/release-objects.yaml
# check the bytes against the listing$ shasum -a 256 nvidia-gpu-operator-v26-7-1-default.yaml
a3d4cab291e48e0d0e667ef49116c6d7ecff91600cd13c1e9c4c23290fcd78dd nvidia-gpu-operator-v26-7-1-default.yaml
# render this base from the signed package; step 3 uploads this directory$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v26.7.1@sha256:03fa8aec9221b64cc5c25f3334775338a9f98c0529bad66f12340d124c238b71 --base default --work-dir ./nvidia-gpu-operator-v26-7-1-default --non-interactive --namespace gpu-operator
2. Compare with another version or base Not run for this entry
The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 6 other bases in the Catalog, aicr-eks-training, driver-580.105.08, driver-580.126.20, external-nfd, preinstalled-driver and preinstalled-driver-and-toolkit. The Catalog holds 3 other versions, v25.10.1, v26.3.2 and v26.3.3.
# fetch the aicr-eks-training base of the same version$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-aicr-eks-training.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/aicr-eks-training/r001/rendered/release-objects.yaml
# list what differs between the two bases$ cub config diff nvidia-gpu-operator-v26-7-1-default.yaml nvidia-gpu-operator-v26-7-1-aicr-eks-training.yaml --summary
# fetch the default base at version v26.3.3$ curl -fsSL -o nvidia-gpu-operator-v26-3-3-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.3.3/revisions/default/r001/rendered/release-objects.yaml
# list what changed from v26.3.3 to v26.7.1$ cub config diff nvidia-gpu-operator-v26-3-3-default.yaml nvidia-gpu-operator-v26-7-1-default.yaml --summary
Replace each value in angle brackets with a name of your own. The entry id may already exist as a Space in your organization, and the package name as a Component.
In the live walk, a Space named for the nginx entry's id and a Component named bitnami-nginx already existed, so the walk chose its own names. The --component flag sets the Component label the upload writes on the Space, which is the package name when you omit it.
The cub installer plugin reads your organization from CUB_CONTEXT and ignores --context. If you use a context other than your default, export CUB_CONTEXT first, or the plugin works in your default organization.
# sign in; steps 3 to 5 write to your ConfigHub organization$ cub auth login
# upload step 1's directory as a Space of Units, under names you choose$ cub installer upload --work-dir ./nvidia-gpu-operator-v26-7-1-default --space <your-space> --component <your-component>
# list the Units the upload created$ cub unit list --space <your-space>
4. Deploy it Not run for this entry
No delivery run is recorded for this entry. Argo CD has not run, Flux has not run, and kubectl has not run. The commands name the Target workshop/target, which cub cluster up --name workshop creates on a local kind cluster with Argo CD. Use your own Target for a real destination. The base carries 8 CRDs it needs, so the destination does not supply them. Read the log of the live walk on 2026-10-08.
Use the Space name you chose in step 3. The delete command is needed because the cloned installer-record Unit carries the Target and Argo CD v3.5.4 cannot read it, a defect seen on cub v0.8.7 and server v0.8.9.
Without that line the walk deployed nothing and Argo CD showed Unknown, while every cub command exited 0. The walk ran the four commands in this order and did not try them without the first publish.
ConfigHub shows nothing when Argo CD fails to read a Release. Run kubectl -n argocd get applications.argoproj.io and read the Sync column, because Healthy alone is not a pass. Argo CD took between 18 seconds and about 5 minutes to read a Release on a cluster made without argobot.
The walk made its cluster with cub cluster up --no-argobot. That command creates two Spaces, a Worker, a Target and a Trigger, opens ports 30010 to 30019 on the machine, and installs Argo CD from an unpinned upstream manifest.
Removing the ConfigHub side does not remove the workload. In the walk, deleting the Application Unit and the Spaces left the Application and its pods running, because the root Application does not prune.
# clone the base onto a Target as a dev variant$ cub variant create dev <your-space> --target workshop/target --space-pattern "template:<your-space>-dev"
# publish the Release that the cluster's Argo CD pulls$ cub release publish <your-space>-dev
# delete the installer record, which Argo CD cannot read$ cub unit delete --space <your-space>-dev installer-record
# publish again without it$ cub release publish <your-space>-dev
5. Promote a change Not run for this entry
No promotion is recorded for this entry. Promotion carries a change in the base to the dev variant. The base changes when you edit a Unit or upload a newer version into the same Space. Read the log of the live walk on 2026-10-08.
The promotion changes the dev Space and publishes nothing. It also adds the installer-record Unit back with the Target. The change reaches the cluster only after the delete and the publish.
The preview lists the whole installer record as added. In the walk, the preview of a one-label change to gpu-operator ran to 405 lines, and about 400 of them were that record.
# preview what the dev variant would take from the base$ cub variant promote <your-space>-dev --dry-run -o mutations
# promote once you have read the preview$ cub variant promote <your-space>-dev --change-desc "Pull the reviewed base forward"
# delete the installer record that the promotion adds back$ cub unit delete --space <your-space>-dev installer-record
# publish the Release that carries the change$ cub release publish <your-space>-dev
Helm chart, base aicr-eks-training, version v26.7.1What is fixed, and what you supply
Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.
chart is nvidia/gpu-operator
version is v26.7.1
base is aicr-eks-training
valuesProfile is recipes/nvidia/gpu-operator/v26.7.1/effective-values-aicr-eks-training.yaml
namespace is gpu-operator
releaseName is gpu-operator
capabilityProfile is {"apiVersions":[],"kubeVersion":"1.31.0"}
Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.
gpu-operator CRD included in this base; it must be established before Kubernetes accepts the rendered ClusterPolicy object Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
This entry's plan, and how to test it
These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.
When you deliver. Apply the 5 CustomResourceDefinition objects first. Wait until every named definition reports the Established condition. The listing gives the rest. Who: whatever applies the objects. Written down. Not run by the Catalog.
Around an upgrade. Before an upgrade, move the CRDs to the new version. Helm does not upgrade CRDs from a chart's crds directory, so the chart ships this Job. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. Before deleting, remove a chart-managed GPUCluster and wait for it to go. The Job deletes the chart-managed GPUCluster object and waits until it is gone, so the operator can drain workloads under its finalizer while it is still running. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Test the install steps yourself.This script carries them out with kubectl on a cluster you choose, with no account. Read it first and use a throwaway cluster. The Catalog has no recorded run of this script.
Test the plain objects.A second script tests the retained objects themselves with kubectl, and it needs no cub and no account. The Catalog has no recorded run of this script.
The Catalog rendered this entry and retains its 13 objects in one file.
An upload can create more Units than the objects counted here. The installer renders a Namespace, and the upload adds an installer-record Unit.
# fetch the retained objects for this entry$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-aicr-eks-training.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/aicr-eks-training/r001/rendered/release-objects.yaml
# check the bytes against the listing$ shasum -a 256 nvidia-gpu-operator-v26-7-1-aicr-eks-training.yaml
4bd9d60ec2d64a15f28d175934c33d26efd49990a5a28d36b463182b807f9a9b nvidia-gpu-operator-v26-7-1-aicr-eks-training.yaml
# render this base from the signed package; step 3 uploads this directory$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v26.7.1@sha256:03fa8aec9221b64cc5c25f3334775338a9f98c0529bad66f12340d124c238b71 --base aicr-eks-training --work-dir ./nvidia-gpu-operator-v26-7-1-aicr-eks-training --non-interactive --namespace gpu-operator
2. Compare with another version or base Not run for this entry
The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 6 other bases in the Catalog, default, driver-580.105.08, driver-580.126.20, external-nfd, preinstalled-driver and preinstalled-driver-and-toolkit. The Catalog holds 3 other versions, v25.10.1, v26.3.2 and v26.3.3.
# fetch the default base of the same version$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/default/r001/rendered/release-objects.yaml
# list what differs between the two bases$ cub config diff nvidia-gpu-operator-v26-7-1-aicr-eks-training.yaml nvidia-gpu-operator-v26-7-1-default.yaml --summary
# fetch the aicr-eks-training base at version v26.3.3$ curl -fsSL -o nvidia-gpu-operator-v26-3-3-aicr-eks-training.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.3.3/revisions/aicr-eks-training/r001/rendered/release-objects.yaml
# list what changed from v26.3.3 to v26.7.1$ cub config diff nvidia-gpu-operator-v26-3-3-aicr-eks-training.yaml nvidia-gpu-operator-v26-7-1-aicr-eks-training.yaml --summary
Replace each value in angle brackets with a name of your own. The entry id may already exist as a Space in your organization, and the package name as a Component.
In the live walk, a Space named for the nginx entry's id and a Component named bitnami-nginx already existed, so the walk chose its own names. The --component flag sets the Component label the upload writes on the Space, which is the package name when you omit it.
The cub installer plugin reads your organization from CUB_CONTEXT and ignores --context. If you use a context other than your default, export CUB_CONTEXT first, or the plugin works in your default organization.
# sign in; steps 3 to 5 write to your ConfigHub organization$ cub auth login
# upload step 1's directory as a Space of Units, under names you choose$ cub installer upload --work-dir ./nvidia-gpu-operator-v26-7-1-aicr-eks-training --space <your-space> --component <your-component>
# list the Units the upload created$ cub unit list --space <your-space>
4. Deploy it Not run for this entry
No delivery run is recorded for this entry. Argo CD has not run, Flux has not run, and kubectl has not run. The commands name the Target workshop/target, which cub cluster up --name workshop creates on a local kind cluster with Argo CD. Use your own Target for a real destination. The base carries 5 CRDs it needs, so the destination does not supply them. Read the log of the live walk on 2026-10-08.
Use the Space name you chose in step 3. The delete command is needed because the cloned installer-record Unit carries the Target and Argo CD v3.5.4 cannot read it, a defect seen on cub v0.8.7 and server v0.8.9.
Without that line the walk deployed nothing and Argo CD showed Unknown, while every cub command exited 0. The walk ran the four commands in this order and did not try them without the first publish.
ConfigHub shows nothing when Argo CD fails to read a Release. Run kubectl -n argocd get applications.argoproj.io and read the Sync column, because Healthy alone is not a pass. Argo CD took between 18 seconds and about 5 minutes to read a Release on a cluster made without argobot.
The walk made its cluster with cub cluster up --no-argobot. That command creates two Spaces, a Worker, a Target and a Trigger, opens ports 30010 to 30019 on the machine, and installs Argo CD from an unpinned upstream manifest.
Removing the ConfigHub side does not remove the workload. In the walk, deleting the Application Unit and the Spaces left the Application and its pods running, because the root Application does not prune.
# clone the base onto a Target as a dev variant$ cub variant create dev <your-space> --target workshop/target --space-pattern "template:<your-space>-dev"
# publish the Release that the cluster's Argo CD pulls$ cub release publish <your-space>-dev
# delete the installer record, which Argo CD cannot read$ cub unit delete --space <your-space>-dev installer-record
# publish again without it$ cub release publish <your-space>-dev
5. Promote a change Not run for this entry
No promotion is recorded for this entry. Promotion carries a change in the base to the dev variant. The base changes when you edit a Unit or upload a newer version into the same Space. Read the log of the live walk on 2026-10-08.
The promotion changes the dev Space and publishes nothing. It also adds the installer-record Unit back with the Target. The change reaches the cluster only after the delete and the publish.
The preview lists the whole installer record as added. In the walk, the preview of a one-label change to gpu-operator ran to 405 lines, and about 400 of them were that record.
# preview what the dev variant would take from the base$ cub variant promote <your-space>-dev --dry-run -o mutations
# promote once you have read the preview$ cub variant promote <your-space>-dev --change-desc "Pull the reviewed base forward"
# delete the installer record that the promotion adds back$ cub unit delete --space <your-space>-dev installer-record
# publish the Release that carries the change$ cub release publish <your-space>-dev
Helm chart, base driver-580.105.08, version v26.7.1What is fixed, and what you supply
Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.
chart is nvidia/gpu-operator
version is v26.7.1
base is driver-580.105.08
valuesProfile is recipes/nvidia/gpu-operator/v26.7.1/effective-values-driver-580.105.08.yaml
namespace is gpu-operator
releaseName is gpu-operator
capabilityProfile is {"apiVersions":[],"kubeVersion":"1.31.0"}
Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.
gpu-operator CRD included in this base; it must be established before Kubernetes accepts the rendered ClusterPolicy object Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
This entry's plan, and how to test it
These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.
When you deliver. Apply the 8 CustomResourceDefinition objects first. Wait until every named definition reports the Established condition. The listing gives the rest. Who: whatever applies the objects. Written down. Not run by the Catalog.
Around an upgrade. Before an upgrade, move the CRDs to the new version. Helm does not upgrade CRDs from a chart's crds directory, so the chart ships this Job. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. Before deleting, remove a chart-managed GPUCluster and wait for it to go. The Job deletes the chart-managed GPUCluster object and waits until it is gone, so the operator can drain workloads under its finalizer while it is still running. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. After deleting, prune node-feature-discovery labels from the nodes. The Job runs nfd-master -prune, which removes node-feature-discovery labels, annotations and taints from every node, with its own ServiceAccount, ClusterRole and ClusterRoleBinding. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Test the install steps yourself.This script carries them out with kubectl on a cluster you choose, with no account. Read it first and use a throwaway cluster. The Catalog has no recorded run of this script.
Test the plain objects.A second script tests the retained objects themselves with kubectl, and it needs no cub and no account. The Catalog has no recorded run of this script.
The Catalog rendered this entry and retains its 27 objects in one file.
An upload can create more Units than the objects counted here. The installer renders a Namespace, and the upload adds an installer-record Unit.
# fetch the retained objects for this entry$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-driver-580-105-08.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/driver-580.105.08/r001/rendered/release-objects.yaml
# check the bytes against the listing$ shasum -a 256 nvidia-gpu-operator-v26-7-1-driver-580-105-08.yaml
a7c7497145609bb16a06dda26b387625f75b388360ba9589d19ad6e6459a63f6 nvidia-gpu-operator-v26-7-1-driver-580-105-08.yaml
# render this base from the signed package; step 3 uploads this directory$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v26.7.1@sha256:03fa8aec9221b64cc5c25f3334775338a9f98c0529bad66f12340d124c238b71 --base driver-580.105.08 --work-dir ./nvidia-gpu-operator-v26-7-1-driver-580-105-08 --non-interactive --namespace gpu-operator
2. Compare with another version or base Not run for this entry
The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 6 other bases in the Catalog, aicr-eks-training, default, driver-580.126.20, external-nfd, preinstalled-driver and preinstalled-driver-and-toolkit. The Catalog holds 3 other versions, v25.10.1, v26.3.2 and v26.3.3.
# fetch the default base of the same version$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/default/r001/rendered/release-objects.yaml
# list what differs between the two bases$ cub config diff nvidia-gpu-operator-v26-7-1-driver-580-105-08.yaml nvidia-gpu-operator-v26-7-1-default.yaml --summary
# fetch the driver-580.105.08 base at version v26.3.3$ curl -fsSL -o nvidia-gpu-operator-v26-3-3-driver-580-105-08.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.3.3/revisions/driver-580.105.08/r001/rendered/release-objects.yaml
# list what changed from v26.3.3 to v26.7.1$ cub config diff nvidia-gpu-operator-v26-3-3-driver-580-105-08.yaml nvidia-gpu-operator-v26-7-1-driver-580-105-08.yaml --summary
Replace each value in angle brackets with a name of your own. The entry id may already exist as a Space in your organization, and the package name as a Component.
In the live walk, a Space named for the nginx entry's id and a Component named bitnami-nginx already existed, so the walk chose its own names. The --component flag sets the Component label the upload writes on the Space, which is the package name when you omit it.
The cub installer plugin reads your organization from CUB_CONTEXT and ignores --context. If you use a context other than your default, export CUB_CONTEXT first, or the plugin works in your default organization.
# sign in; steps 3 to 5 write to your ConfigHub organization$ cub auth login
# upload step 1's directory as a Space of Units, under names you choose$ cub installer upload --work-dir ./nvidia-gpu-operator-v26-7-1-driver-580-105-08 --space <your-space> --component <your-component>
# list the Units the upload created$ cub unit list --space <your-space>
4. Deploy it Not run for this entry
No delivery run is recorded for this entry. Argo CD has not run, Flux has not run, and kubectl has not run. The commands name the Target workshop/target, which cub cluster up --name workshop creates on a local kind cluster with Argo CD. Use your own Target for a real destination. The base carries 8 CRDs it needs, so the destination does not supply them. Read the log of the live walk on 2026-10-08.
Use the Space name you chose in step 3. The delete command is needed because the cloned installer-record Unit carries the Target and Argo CD v3.5.4 cannot read it, a defect seen on cub v0.8.7 and server v0.8.9.
Without that line the walk deployed nothing and Argo CD showed Unknown, while every cub command exited 0. The walk ran the four commands in this order and did not try them without the first publish.
ConfigHub shows nothing when Argo CD fails to read a Release. Run kubectl -n argocd get applications.argoproj.io and read the Sync column, because Healthy alone is not a pass. Argo CD took between 18 seconds and about 5 minutes to read a Release on a cluster made without argobot.
The walk made its cluster with cub cluster up --no-argobot. That command creates two Spaces, a Worker, a Target and a Trigger, opens ports 30010 to 30019 on the machine, and installs Argo CD from an unpinned upstream manifest.
Removing the ConfigHub side does not remove the workload. In the walk, deleting the Application Unit and the Spaces left the Application and its pods running, because the root Application does not prune.
# clone the base onto a Target as a dev variant$ cub variant create dev <your-space> --target workshop/target --space-pattern "template:<your-space>-dev"
# publish the Release that the cluster's Argo CD pulls$ cub release publish <your-space>-dev
# delete the installer record, which Argo CD cannot read$ cub unit delete --space <your-space>-dev installer-record
# publish again without it$ cub release publish <your-space>-dev
5. Promote a change Not run for this entry
No promotion is recorded for this entry. Promotion carries a change in the base to the dev variant. The base changes when you edit a Unit or upload a newer version into the same Space. Read the log of the live walk on 2026-10-08.
The promotion changes the dev Space and publishes nothing. It also adds the installer-record Unit back with the Target. The change reaches the cluster only after the delete and the publish.
The preview lists the whole installer record as added. In the walk, the preview of a one-label change to gpu-operator ran to 405 lines, and about 400 of them were that record.
# preview what the dev variant would take from the base$ cub variant promote <your-space>-dev --dry-run -o mutations
# promote once you have read the preview$ cub variant promote <your-space>-dev --change-desc "Pull the reviewed base forward"
# delete the installer record that the promotion adds back$ cub unit delete --space <your-space>-dev installer-record
# publish the Release that carries the change$ cub release publish <your-space>-dev
Helm chart, base driver-580.126.20, version v26.7.1What is fixed, and what you supply
Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.
chart is nvidia/gpu-operator
version is v26.7.1
base is driver-580.126.20
valuesProfile is recipes/nvidia/gpu-operator/v26.7.1/effective-values-driver-580.126.20.yaml
namespace is gpu-operator
releaseName is gpu-operator
capabilityProfile is {"apiVersions":[],"kubeVersion":"1.31.0"}
Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.
gpu-operator CRD included in this base; it must be established before Kubernetes accepts the rendered ClusterPolicy object Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
This entry's plan, and how to test it
These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.
When you deliver. Apply the 8 CustomResourceDefinition objects first. Wait until every named definition reports the Established condition. The listing gives the rest. Who: whatever applies the objects. Written down. Not run by the Catalog.
Around an upgrade. Before an upgrade, move the CRDs to the new version. Helm does not upgrade CRDs from a chart's crds directory, so the chart ships this Job. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. Before deleting, remove a chart-managed GPUCluster and wait for it to go. The Job deletes the chart-managed GPUCluster object and waits until it is gone, so the operator can drain workloads under its finalizer while it is still running. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. After deleting, prune node-feature-discovery labels from the nodes. The Job runs nfd-master -prune, which removes node-feature-discovery labels, annotations and taints from every node, with its own ServiceAccount, ClusterRole and ClusterRoleBinding. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Test the install steps yourself.This script carries them out with kubectl on a cluster you choose, with no account. Read it first and use a throwaway cluster. The Catalog has no recorded run of this script.
Test the plain objects.A second script tests the retained objects themselves with kubectl, and it needs no cub and no account. The Catalog has no recorded run of this script.
The Catalog rendered this entry and retains its 27 objects in one file.
An upload can create more Units than the objects counted here. The installer renders a Namespace, and the upload adds an installer-record Unit.
# fetch the retained objects for this entry$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-driver-580-126-20.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/driver-580.126.20/r001/rendered/release-objects.yaml
# check the bytes against the listing$ shasum -a 256 nvidia-gpu-operator-v26-7-1-driver-580-126-20.yaml
07c886e36a064b51cc99954ae5f3e98f3ca07d3ba51e1721e7affbf6a01654aa nvidia-gpu-operator-v26-7-1-driver-580-126-20.yaml
# render this base from the signed package; step 3 uploads this directory$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v26.7.1@sha256:03fa8aec9221b64cc5c25f3334775338a9f98c0529bad66f12340d124c238b71 --base driver-580.126.20 --work-dir ./nvidia-gpu-operator-v26-7-1-driver-580-126-20 --non-interactive --namespace gpu-operator
2. Compare with another version or base Not run for this entry
The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 6 other bases in the Catalog, aicr-eks-training, default, driver-580.105.08, external-nfd, preinstalled-driver and preinstalled-driver-and-toolkit. The Catalog holds 3 other versions, v25.10.1, v26.3.2 and v26.3.3.
# fetch the default base of the same version$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/default/r001/rendered/release-objects.yaml
# list what differs between the two bases$ cub config diff nvidia-gpu-operator-v26-7-1-driver-580-126-20.yaml nvidia-gpu-operator-v26-7-1-default.yaml --summary
# fetch the driver-580.126.20 base at version v25.10.1$ curl -fsSL -o nvidia-gpu-operator-v25-10-1-driver-580-126-20.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v25.10.1/revisions/driver-580.126.20/r001/rendered/release-objects.yaml
# list what changed from v25.10.1 to v26.7.1$ cub config diff nvidia-gpu-operator-v25-10-1-driver-580-126-20.yaml nvidia-gpu-operator-v26-7-1-driver-580-126-20.yaml --summary
Replace each value in angle brackets with a name of your own. The entry id may already exist as a Space in your organization, and the package name as a Component.
In the live walk, a Space named for the nginx entry's id and a Component named bitnami-nginx already existed, so the walk chose its own names. The --component flag sets the Component label the upload writes on the Space, which is the package name when you omit it.
The cub installer plugin reads your organization from CUB_CONTEXT and ignores --context. If you use a context other than your default, export CUB_CONTEXT first, or the plugin works in your default organization.
# sign in; steps 3 to 5 write to your ConfigHub organization$ cub auth login
# upload step 1's directory as a Space of Units, under names you choose$ cub installer upload --work-dir ./nvidia-gpu-operator-v26-7-1-driver-580-126-20 --space <your-space> --component <your-component>
# list the Units the upload created$ cub unit list --space <your-space>
4. Deploy it Not run for this entry
No delivery run is recorded for this entry. Argo CD has not run, Flux has not run, and kubectl has not run. The commands name the Target workshop/target, which cub cluster up --name workshop creates on a local kind cluster with Argo CD. Use your own Target for a real destination. The base carries 8 CRDs it needs, so the destination does not supply them. Read the log of the live walk on 2026-10-08.
Use the Space name you chose in step 3. The delete command is needed because the cloned installer-record Unit carries the Target and Argo CD v3.5.4 cannot read it, a defect seen on cub v0.8.7 and server v0.8.9.
Without that line the walk deployed nothing and Argo CD showed Unknown, while every cub command exited 0. The walk ran the four commands in this order and did not try them without the first publish.
ConfigHub shows nothing when Argo CD fails to read a Release. Run kubectl -n argocd get applications.argoproj.io and read the Sync column, because Healthy alone is not a pass. Argo CD took between 18 seconds and about 5 minutes to read a Release on a cluster made without argobot.
The walk made its cluster with cub cluster up --no-argobot. That command creates two Spaces, a Worker, a Target and a Trigger, opens ports 30010 to 30019 on the machine, and installs Argo CD from an unpinned upstream manifest.
Removing the ConfigHub side does not remove the workload. In the walk, deleting the Application Unit and the Spaces left the Application and its pods running, because the root Application does not prune.
# clone the base onto a Target as a dev variant$ cub variant create dev <your-space> --target workshop/target --space-pattern "template:<your-space>-dev"
# publish the Release that the cluster's Argo CD pulls$ cub release publish <your-space>-dev
# delete the installer record, which Argo CD cannot read$ cub unit delete --space <your-space>-dev installer-record
# publish again without it$ cub release publish <your-space>-dev
5. Promote a change Not run for this entry
No promotion is recorded for this entry. Promotion carries a change in the base to the dev variant. The base changes when you edit a Unit or upload a newer version into the same Space. Read the log of the live walk on 2026-10-08.
The promotion changes the dev Space and publishes nothing. It also adds the installer-record Unit back with the Target. The change reaches the cluster only after the delete and the publish.
The preview lists the whole installer record as added. In the walk, the preview of a one-label change to gpu-operator ran to 405 lines, and about 400 of them were that record.
# preview what the dev variant would take from the base$ cub variant promote <your-space>-dev --dry-run -o mutations
# promote once you have read the preview$ cub variant promote <your-space>-dev --change-desc "Pull the reviewed base forward"
# delete the installer record that the promotion adds back$ cub unit delete --space <your-space>-dev installer-record
# publish the Release that carries the change$ cub release publish <your-space>-dev
Helm chart, base external-nfd, version v26.7.1What is fixed, and what you supply
Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.
chart is nvidia/gpu-operator
version is v26.7.1
base is external-nfd
valuesProfile is recipes/nvidia/gpu-operator/v26.7.1/effective-values-external-nfd.yaml
namespace is gpu-operator
releaseName is gpu-operator
capabilityProfile is {"apiVersions":[],"kubeVersion":"1.31.0"}
Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.
gpu-operator CRD included in this base; it must be established before Kubernetes accepts the rendered ClusterPolicy object Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
This entry's plan, and how to test it
These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.
When you deliver. Apply the 5 CustomResourceDefinition objects first. Wait until every named definition reports the Established condition. The listing gives the rest. Who: whatever applies the objects. Written down. Not run by the Catalog.
Around an upgrade. Before an upgrade, move the CRDs to the new version. Helm does not upgrade CRDs from a chart's crds directory, so the chart ships this Job. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. Before deleting, remove a chart-managed GPUCluster and wait for it to go. The Job deletes the chart-managed GPUCluster object and waits until it is gone, so the operator can drain workloads under its finalizer while it is still running. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Test the install steps yourself.This script carries them out with kubectl on a cluster you choose, with no account. Read it first and use a throwaway cluster. The Catalog has no recorded run of this script.
Test the plain objects.A second script tests the retained objects themselves with kubectl, and it needs no cub and no account. The Catalog has no recorded run of this script.
The Catalog rendered this entry and retains its 12 objects in one file.
An upload can create more Units than the objects counted here. The installer renders a Namespace, and the upload adds an installer-record Unit.
# fetch the retained objects for this entry$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-external-nfd.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/external-nfd/r001/rendered/release-objects.yaml
# check the bytes against the listing$ shasum -a 256 nvidia-gpu-operator-v26-7-1-external-nfd.yaml
a6331c4c2f27f1b5124c97a8e5074375ff58e0dbfcb48c0a12104dba2617b489 nvidia-gpu-operator-v26-7-1-external-nfd.yaml
# render this base from the signed package; step 3 uploads this directory$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v26.7.1@sha256:03fa8aec9221b64cc5c25f3334775338a9f98c0529bad66f12340d124c238b71 --base external-nfd --work-dir ./nvidia-gpu-operator-v26-7-1-external-nfd --non-interactive --namespace gpu-operator
2. Compare with another version or base Not run for this entry
The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 6 other bases in the Catalog, aicr-eks-training, default, driver-580.105.08, driver-580.126.20, preinstalled-driver and preinstalled-driver-and-toolkit. The Catalog holds 3 other versions, v25.10.1, v26.3.2 and v26.3.3.
# fetch the default base of the same version$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/default/r001/rendered/release-objects.yaml
# list what differs between the two bases$ cub config diff nvidia-gpu-operator-v26-7-1-external-nfd.yaml nvidia-gpu-operator-v26-7-1-default.yaml --summary
# fetch the external-nfd base at version v26.3.3$ curl -fsSL -o nvidia-gpu-operator-v26-3-3-external-nfd.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.3.3/revisions/external-nfd/r001/rendered/release-objects.yaml
# list what changed from v26.3.3 to v26.7.1$ cub config diff nvidia-gpu-operator-v26-3-3-external-nfd.yaml nvidia-gpu-operator-v26-7-1-external-nfd.yaml --summary
Replace each value in angle brackets with a name of your own. The entry id may already exist as a Space in your organization, and the package name as a Component.
In the live walk, a Space named for the nginx entry's id and a Component named bitnami-nginx already existed, so the walk chose its own names. The --component flag sets the Component label the upload writes on the Space, which is the package name when you omit it.
The cub installer plugin reads your organization from CUB_CONTEXT and ignores --context. If you use a context other than your default, export CUB_CONTEXT first, or the plugin works in your default organization.
# sign in; steps 3 to 5 write to your ConfigHub organization$ cub auth login
# upload step 1's directory as a Space of Units, under names you choose$ cub installer upload --work-dir ./nvidia-gpu-operator-v26-7-1-external-nfd --space <your-space> --component <your-component>
# list the Units the upload created$ cub unit list --space <your-space>
4. Deploy it Not run for this entry
No delivery run is recorded for this entry. Argo CD has not run, Flux has not run, and kubectl has not run. The commands name the Target workshop/target, which cub cluster up --name workshop creates on a local kind cluster with Argo CD. Use your own Target for a real destination. The base carries 5 CRDs it needs, so the destination does not supply them. Read the log of the live walk on 2026-10-08.
Use the Space name you chose in step 3. The delete command is needed because the cloned installer-record Unit carries the Target and Argo CD v3.5.4 cannot read it, a defect seen on cub v0.8.7 and server v0.8.9.
Without that line the walk deployed nothing and Argo CD showed Unknown, while every cub command exited 0. The walk ran the four commands in this order and did not try them without the first publish.
ConfigHub shows nothing when Argo CD fails to read a Release. Run kubectl -n argocd get applications.argoproj.io and read the Sync column, because Healthy alone is not a pass. Argo CD took between 18 seconds and about 5 minutes to read a Release on a cluster made without argobot.
The walk made its cluster with cub cluster up --no-argobot. That command creates two Spaces, a Worker, a Target and a Trigger, opens ports 30010 to 30019 on the machine, and installs Argo CD from an unpinned upstream manifest.
Removing the ConfigHub side does not remove the workload. In the walk, deleting the Application Unit and the Spaces left the Application and its pods running, because the root Application does not prune.
# clone the base onto a Target as a dev variant$ cub variant create dev <your-space> --target workshop/target --space-pattern "template:<your-space>-dev"
# publish the Release that the cluster's Argo CD pulls$ cub release publish <your-space>-dev
# delete the installer record, which Argo CD cannot read$ cub unit delete --space <your-space>-dev installer-record
# publish again without it$ cub release publish <your-space>-dev
5. Promote a change Not run for this entry
No promotion is recorded for this entry. Promotion carries a change in the base to the dev variant. The base changes when you edit a Unit or upload a newer version into the same Space. Read the log of the live walk on 2026-10-08.
The promotion changes the dev Space and publishes nothing. It also adds the installer-record Unit back with the Target. The change reaches the cluster only after the delete and the publish.
The preview lists the whole installer record as added. In the walk, the preview of a one-label change to gpu-operator ran to 405 lines, and about 400 of them were that record.
# preview what the dev variant would take from the base$ cub variant promote <your-space>-dev --dry-run -o mutations
# promote once you have read the preview$ cub variant promote <your-space>-dev --change-desc "Pull the reviewed base forward"
# delete the installer record that the promotion adds back$ cub unit delete --space <your-space>-dev installer-record
# publish the Release that carries the change$ cub release publish <your-space>-dev
Helm chart, base preinstalled-driver, version v26.7.1What is fixed, and what you supply
Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.
chart is nvidia/gpu-operator
version is v26.7.1
base is preinstalled-driver
valuesProfile is recipes/nvidia/gpu-operator/v26.7.1/effective-values-preinstalled-driver.yaml
namespace is gpu-operator
releaseName is gpu-operator
capabilityProfile is {"apiVersions":[],"kubeVersion":"1.31.0"}
Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.
gpu-operator CRD included in this base; it must be established before Kubernetes accepts the rendered ClusterPolicy object Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
This entry's plan, and how to test it
These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.
When you deliver. Apply the 8 CustomResourceDefinition objects first. Wait until every named definition reports the Established condition. The listing gives the rest. Who: whatever applies the objects. Written down. Not run by the Catalog.
Around an upgrade. Before an upgrade, move the CRDs to the new version. Helm does not upgrade CRDs from a chart's crds directory, so the chart ships this Job. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. Before deleting, remove a chart-managed GPUCluster and wait for it to go. The Job deletes the chart-managed GPUCluster object and waits until it is gone, so the operator can drain workloads under its finalizer while it is still running. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. After deleting, prune node-feature-discovery labels from the nodes. The Job runs nfd-master -prune, which removes node-feature-discovery labels, annotations and taints from every node, with its own ServiceAccount, ClusterRole and ClusterRoleBinding. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Test the install steps yourself.This script carries them out with kubectl on a cluster you choose, with no account. Read it first and use a throwaway cluster. The Catalog has no recorded run of this script.
Test the plain objects.A second script tests the retained objects themselves with kubectl, and it needs no cub and no account. The Catalog has no recorded run of this script.
The Catalog rendered this entry and retains its 27 objects in one file.
An upload can create more Units than the objects counted here. The installer renders a Namespace, and the upload adds an installer-record Unit.
# fetch the retained objects for this entry$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-preinstalled-driver.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/preinstalled-driver/r001/rendered/release-objects.yaml
# check the bytes against the listing$ shasum -a 256 nvidia-gpu-operator-v26-7-1-preinstalled-driver.yaml
98a886b6a43765364c65a2b93d489f430347f3fd8a02a35d5bc03015d675fe36 nvidia-gpu-operator-v26-7-1-preinstalled-driver.yaml
# render this base from the signed package; step 3 uploads this directory$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v26.7.1@sha256:03fa8aec9221b64cc5c25f3334775338a9f98c0529bad66f12340d124c238b71 --base preinstalled-driver --work-dir ./nvidia-gpu-operator-v26-7-1-preinstalled-driver --non-interactive --namespace gpu-operator
2. Compare with another version or base Not run for this entry
The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 6 other bases in the Catalog, aicr-eks-training, default, driver-580.105.08, driver-580.126.20, external-nfd and preinstalled-driver-and-toolkit. The Catalog holds 3 other versions, v25.10.1, v26.3.2 and v26.3.3.
# fetch the default base of the same version$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/default/r001/rendered/release-objects.yaml
# list what differs between the two bases$ cub config diff nvidia-gpu-operator-v26-7-1-preinstalled-driver.yaml nvidia-gpu-operator-v26-7-1-default.yaml --summary
# fetch the preinstalled-driver base at version v26.3.3$ curl -fsSL -o nvidia-gpu-operator-v26-3-3-preinstalled-driver.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.3.3/revisions/preinstalled-driver/r001/rendered/release-objects.yaml
# list what changed from v26.3.3 to v26.7.1$ cub config diff nvidia-gpu-operator-v26-3-3-preinstalled-driver.yaml nvidia-gpu-operator-v26-7-1-preinstalled-driver.yaml --summary
Replace each value in angle brackets with a name of your own. The entry id may already exist as a Space in your organization, and the package name as a Component.
In the live walk, a Space named for the nginx entry's id and a Component named bitnami-nginx already existed, so the walk chose its own names. The --component flag sets the Component label the upload writes on the Space, which is the package name when you omit it.
The cub installer plugin reads your organization from CUB_CONTEXT and ignores --context. If you use a context other than your default, export CUB_CONTEXT first, or the plugin works in your default organization.
# sign in; steps 3 to 5 write to your ConfigHub organization$ cub auth login
# upload step 1's directory as a Space of Units, under names you choose$ cub installer upload --work-dir ./nvidia-gpu-operator-v26-7-1-preinstalled-driver --space <your-space> --component <your-component>
# list the Units the upload created$ cub unit list --space <your-space>
4. Deploy it Not run for this entry
No delivery run is recorded for this entry. Argo CD has not run, Flux has not run, and kubectl has not run. The commands name the Target workshop/target, which cub cluster up --name workshop creates on a local kind cluster with Argo CD. Use your own Target for a real destination. The base carries 8 CRDs it needs, so the destination does not supply them. Read the log of the live walk on 2026-10-08.
Use the Space name you chose in step 3. The delete command is needed because the cloned installer-record Unit carries the Target and Argo CD v3.5.4 cannot read it, a defect seen on cub v0.8.7 and server v0.8.9.
Without that line the walk deployed nothing and Argo CD showed Unknown, while every cub command exited 0. The walk ran the four commands in this order and did not try them without the first publish.
ConfigHub shows nothing when Argo CD fails to read a Release. Run kubectl -n argocd get applications.argoproj.io and read the Sync column, because Healthy alone is not a pass. Argo CD took between 18 seconds and about 5 minutes to read a Release on a cluster made without argobot.
The walk made its cluster with cub cluster up --no-argobot. That command creates two Spaces, a Worker, a Target and a Trigger, opens ports 30010 to 30019 on the machine, and installs Argo CD from an unpinned upstream manifest.
Removing the ConfigHub side does not remove the workload. In the walk, deleting the Application Unit and the Spaces left the Application and its pods running, because the root Application does not prune.
# clone the base onto a Target as a dev variant$ cub variant create dev <your-space> --target workshop/target --space-pattern "template:<your-space>-dev"
# publish the Release that the cluster's Argo CD pulls$ cub release publish <your-space>-dev
# delete the installer record, which Argo CD cannot read$ cub unit delete --space <your-space>-dev installer-record
# publish again without it$ cub release publish <your-space>-dev
5. Promote a change Not run for this entry
No promotion is recorded for this entry. Promotion carries a change in the base to the dev variant. The base changes when you edit a Unit or upload a newer version into the same Space. Read the log of the live walk on 2026-10-08.
The promotion changes the dev Space and publishes nothing. It also adds the installer-record Unit back with the Target. The change reaches the cluster only after the delete and the publish.
The preview lists the whole installer record as added. In the walk, the preview of a one-label change to gpu-operator ran to 405 lines, and about 400 of them were that record.
# preview what the dev variant would take from the base$ cub variant promote <your-space>-dev --dry-run -o mutations
# promote once you have read the preview$ cub variant promote <your-space>-dev --change-desc "Pull the reviewed base forward"
# delete the installer record that the promotion adds back$ cub unit delete --space <your-space>-dev installer-record
# publish the Release that carries the change$ cub release publish <your-space>-dev
Helm chart, base preinstalled-driver-and-toolkit, version v26.7.1What is fixed, and what you supply
Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.
chart is nvidia/gpu-operator
version is v26.7.1
base is preinstalled-driver-and-toolkit
valuesProfile is recipes/nvidia/gpu-operator/v26.7.1/effective-values-preinstalled-driver-and-toolkit.yaml
namespace is gpu-operator
releaseName is gpu-operator
capabilityProfile is {"apiVersions":[],"kubeVersion":"1.31.0"}
Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.
gpu-operator CRD included in this base; it must be established before Kubernetes accepts the rendered ClusterPolicy object Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
CRD included in this base and applied before the workloads that use it Declared. Not checked on any destination.
This entry's plan, and how to test it
These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.
When you deliver. Apply the 8 CustomResourceDefinition objects first. Wait until every named definition reports the Established condition. The listing gives the rest. Who: whatever applies the objects. Written down. Not run by the Catalog.
Around an upgrade. Before an upgrade, move the CRDs to the new version. Helm does not upgrade CRDs from a chart's crds directory, so the chart ships this Job. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. Before deleting, remove a chart-managed GPUCluster and wait for it to go. The Job deletes the chart-managed GPUCluster object and waits until it is gone, so the operator can drain workloads under its finalizer while it is still running. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Around a delete. After deleting, prune node-feature-discovery labels from the nodes. The Job runs nfd-master -prune, which removes node-feature-discovery labels, annotations and taints from every node, with its own ServiceAccount, ClusterRole and ClusterRoleBinding. The listing gives the rest. Who: delivery workflow. Written down. Not run by the Catalog.
Test the install steps yourself.This script carries them out with kubectl on a cluster you choose, with no account. Read it first and use a throwaway cluster. The Catalog has no recorded run of this script.
Test the plain objects.A second script tests the retained objects themselves with kubectl, and it needs no cub and no account. The Catalog has no recorded run of this script.
The Catalog rendered this entry and retains its 27 objects in one file.
An upload can create more Units than the objects counted here. The installer renders a Namespace, and the upload adds an installer-record Unit.
# fetch the retained objects for this entry$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-preinstalled-driver-and-toolkit.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/preinstalled-driver-and-toolkit/r001/rendered/release-objects.yaml
# check the bytes against the listing$ shasum -a 256 nvidia-gpu-operator-v26-7-1-preinstalled-driver-and-toolkit.yaml
2b6cb805960b912ddebd8e5ead4b9bfe5a75ec8d6e28816ebcc9173bdf5da82b nvidia-gpu-operator-v26-7-1-preinstalled-driver-and-toolkit.yaml
# render this base from the signed package; step 3 uploads this directory$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/nvidia-gpu-operator:v26.7.1@sha256:03fa8aec9221b64cc5c25f3334775338a9f98c0529bad66f12340d124c238b71 --base preinstalled-driver-and-toolkit --work-dir ./nvidia-gpu-operator-v26-7-1-preinstalled-driver-and-toolkit --non-interactive --namespace gpu-operator
2. Compare with another version or base Not run for this entry
The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 6 other bases in the Catalog, aicr-eks-training, default, driver-580.105.08, driver-580.126.20, external-nfd and preinstalled-driver. The Catalog holds 3 other versions, v25.10.1, v26.3.2 and v26.3.3.
# fetch the default base of the same version$ curl -fsSL -o nvidia-gpu-operator-v26-7-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.7.1/revisions/default/r001/rendered/release-objects.yaml
# list what differs between the two bases$ cub config diff nvidia-gpu-operator-v26-7-1-preinstalled-driver-and-toolkit.yaml nvidia-gpu-operator-v26-7-1-default.yaml --summary
# fetch the preinstalled-driver-and-toolkit base at version v26.3.3$ curl -fsSL -o nvidia-gpu-operator-v26-3-3-preinstalled-driver-and-toolkit.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/nvidia/gpu-operator/v26.3.3/revisions/preinstalled-driver-and-toolkit/r001/rendered/release-objects.yaml
# list what changed from v26.3.3 to v26.7.1$ cub config diff nvidia-gpu-operator-v26-3-3-preinstalled-driver-and-toolkit.yaml nvidia-gpu-operator-v26-7-1-preinstalled-driver-and-toolkit.yaml --summary
Replace each value in angle brackets with a name of your own. The entry id may already exist as a Space in your organization, and the package name as a Component.
In the live walk, a Space named for the nginx entry's id and a Component named bitnami-nginx already existed, so the walk chose its own names. The --component flag sets the Component label the upload writes on the Space, which is the package name when you omit it.
The cub installer plugin reads your organization from CUB_CONTEXT and ignores --context. If you use a context other than your default, export CUB_CONTEXT first, or the plugin works in your default organization.
# sign in; steps 3 to 5 write to your ConfigHub organization$ cub auth login
# upload step 1's directory as a Space of Units, under names you choose$ cub installer upload --work-dir ./nvidia-gpu-operator-v26-7-1-preinstalled-driver-and-toolkit --space <your-space> --component <your-component>
# list the Units the upload created$ cub unit list --space <your-space>
4. Deploy it Not run for this entry
No delivery run is recorded for this entry. Argo CD has not run, Flux has not run, and kubectl has not run. The commands name the Target workshop/target, which cub cluster up --name workshop creates on a local kind cluster with Argo CD. Use your own Target for a real destination. The base carries 8 CRDs it needs, so the destination does not supply them. Read the log of the live walk on 2026-10-08.
Use the Space name you chose in step 3. The delete command is needed because the cloned installer-record Unit carries the Target and Argo CD v3.5.4 cannot read it, a defect seen on cub v0.8.7 and server v0.8.9.
Without that line the walk deployed nothing and Argo CD showed Unknown, while every cub command exited 0. The walk ran the four commands in this order and did not try them without the first publish.
ConfigHub shows nothing when Argo CD fails to read a Release. Run kubectl -n argocd get applications.argoproj.io and read the Sync column, because Healthy alone is not a pass. Argo CD took between 18 seconds and about 5 minutes to read a Release on a cluster made without argobot.
The walk made its cluster with cub cluster up --no-argobot. That command creates two Spaces, a Worker, a Target and a Trigger, opens ports 30010 to 30019 on the machine, and installs Argo CD from an unpinned upstream manifest.
Removing the ConfigHub side does not remove the workload. In the walk, deleting the Application Unit and the Spaces left the Application and its pods running, because the root Application does not prune.
# clone the base onto a Target as a dev variant$ cub variant create dev <your-space> --target workshop/target --space-pattern "template:<your-space>-dev"
# publish the Release that the cluster's Argo CD pulls$ cub release publish <your-space>-dev
# delete the installer record, which Argo CD cannot read$ cub unit delete --space <your-space>-dev installer-record
# publish again without it$ cub release publish <your-space>-dev
5. Promote a change Not run for this entry
No promotion is recorded for this entry. Promotion carries a change in the base to the dev variant. The base changes when you edit a Unit or upload a newer version into the same Space. Read the log of the live walk on 2026-10-08.
The promotion changes the dev Space and publishes nothing. It also adds the installer-record Unit back with the Target. The change reaches the cluster only after the delete and the publish.
The preview lists the whole installer record as added. In the walk, the preview of a one-label change to gpu-operator ran to 405 lines, and about 400 of them were that record.
# preview what the dev variant would take from the base$ cub variant promote <your-space>-dev --dry-run -o mutations
# promote once you have read the preview$ cub variant promote <your-space>-dev --change-desc "Pull the reviewed base forward"
# delete the installer record that the promotion adds back$ cub unit delete --space <your-space>-dev installer-record
# publish the Release that carries the change$ cub release publish <your-space>-dev
After You Render It
The first command writes files and does not apply them. Read the objects and setup requirements, then choose the next job.
cub plugin install confighub/homebrew-tap@cub-scan-v0.7.3 --name scan cub check --format json --output cub-check.json <work-dir>/out/manifests. The check is advisory and does not apply anything.
Apply the rendered manifests with kubectl, or publish reviewed objects as OCI
Each card is one available way to use this chart in the catalog. Some cards are runnable base variants. Others are candidate paths, derived variants, or review notes that explain what still has to be prepared.
Checks: Each card names what was checked and says whether it passed, needs review, was blocked, was not run, or was not needed.
try.sh renders, settles the prerequisites in order, and applies with kubectl; confighub.sh renders and uploads to your ConfigHub Space.
Evidence
Helm render parity receipt
Hooks/actions
No separate hook or action for this row.
Who runs actions?
No separate action runner for this row.
Lifecycle record
The current review found no separate hook or setup step for this base. Open the full record.
Prerequisites
8 prerequisites are declared for this base. Each prerequisite says whether it must be checked before render or before apply.
Next
Review chart analysis and create a recipe candidate
Reason
Promotion needs source and destination ConfigHub Spaces. It has not been tested for this configuration.
Helm outputPassedSaved in ConfigHubNot runLocal clusterNot runSetup stepNot neededGitOps and OCINot runLive Helm comparisonNot runTwo clustersNot runPromotionNot run
Prerequisites still apply. “Not needed” under Setup step means there is no separate hook or setup runner for this configuration; it does not remove the prerequisite listed above.
try.sh renders, settles the prerequisites in order, and applies with kubectl; confighub.sh renders and uploads to your ConfigHub Space.
Evidence
Helm render parity receipt
Hooks/actions
No separate hook or action for this row.
Who runs actions?
No separate action runner for this row.
Lifecycle record
The current review found no separate hook or setup step for this base. Open the full record.
Prerequisites
5 prerequisites are declared for this base. Each prerequisite says whether it must be checked before render or before apply.
Next
Review chart analysis and create a recipe candidate
Reason
Promotion needs source and destination ConfigHub Spaces. It has not been tested for this configuration.
Helm outputPassedSaved in ConfigHubNot runLocal clusterNot runSetup stepNot neededGitOps and OCINot runLive Helm comparisonNot runTwo clustersNot runPromotionNot run
Prerequisites still apply. “Not needed” under Setup step means there is no separate hook or setup runner for this configuration; it does not remove the prerequisite listed above.
try.sh renders, settles the prerequisites in order, and applies with kubectl; confighub.sh renders and uploads to your ConfigHub Space.
Evidence
Helm render parity receipt
Hooks/actions
No separate hook or action for this row.
Who runs actions?
No separate action runner for this row.
Lifecycle record
The current review found no separate hook or setup step for this base. Open the full record.
Prerequisites
8 prerequisites are declared for this base. Each prerequisite says whether it must be checked before render or before apply.
Next
Review chart analysis and create a recipe candidate
Reason
Promotion needs source and destination ConfigHub Spaces. It has not been tested for this configuration.
Helm outputPassedSaved in ConfigHubNot runLocal clusterNot runSetup stepNot neededGitOps and OCINot runLive Helm comparisonNot runTwo clustersNot runPromotionNot run
Prerequisites still apply. “Not needed” under Setup step means there is no separate hook or setup runner for this configuration; it does not remove the prerequisite listed above.
try.sh renders, settles the prerequisites in order, and applies with kubectl; confighub.sh renders and uploads to your ConfigHub Space.
Evidence
Helm render parity receipt
Hooks/actions
No separate hook or action for this row.
Who runs actions?
No separate action runner for this row.
Lifecycle record
The current review found no separate hook or setup step for this base. Open the full record.
Prerequisites
8 prerequisites are declared for this base. Each prerequisite says whether it must be checked before render or before apply.
Next
Review chart analysis and create a recipe candidate
Reason
Promotion needs source and destination ConfigHub Spaces. It has not been tested for this configuration.
Helm outputPassedSaved in ConfigHubNot runLocal clusterNot runSetup stepNot neededGitOps and OCINot runLive Helm comparisonNot runTwo clustersNot runPromotionNot run
Prerequisites still apply. “Not needed” under Setup step means there is no separate hook or setup runner for this configuration; it does not remove the prerequisite listed above.
try.sh renders, settles the prerequisites in order, and applies with kubectl; confighub.sh renders and uploads to your ConfigHub Space.
Evidence
Helm render parity receipt
Hooks/actions
No separate hook or action for this row.
Who runs actions?
No separate action runner for this row.
Lifecycle record
The current review found no separate hook or setup step for this base. Open the full record.
Prerequisites
5 prerequisites are declared for this base. Each prerequisite says whether it must be checked before render or before apply.
Next
Review chart analysis and create a recipe candidate
Reason
Promotion needs source and destination ConfigHub Spaces. It has not been tested for this configuration.
Helm outputPassedSaved in ConfigHubNot runLocal clusterNot runSetup stepNot neededGitOps and OCINot runLive Helm comparisonNot runTwo clustersNot runPromotionNot run
Prerequisites still apply. “Not needed” under Setup step means there is no separate hook or setup runner for this configuration; it does not remove the prerequisite listed above.
try.sh renders, settles the prerequisites in order, and applies with kubectl; confighub.sh renders and uploads to your ConfigHub Space.
Evidence
Helm render parity receipt
Hooks/actions
No separate hook or action for this row.
Who runs actions?
No separate action runner for this row.
Lifecycle record
The current review found no separate hook or setup step for this base. Open the full record.
Prerequisites
8 prerequisites are declared for this base. Each prerequisite says whether it must be checked before render or before apply.
Next
Review chart analysis and create a recipe candidate
Reason
Promotion needs source and destination ConfigHub Spaces. It has not been tested for this configuration.
Helm outputPassedSaved in ConfigHubNot runLocal clusterNot runSetup stepNot neededGitOps and OCINot runLive Helm comparisonNot runTwo clustersNot runPromotionNot run
Prerequisites still apply. “Not needed” under Setup step means there is no separate hook or setup runner for this configuration; it does not remove the prerequisite listed above.
try.sh renders, settles the prerequisites in order, and applies with kubectl; confighub.sh renders and uploads to your ConfigHub Space.
Evidence
Helm render parity receipt
Hooks/actions
No separate hook or action for this row.
Who runs actions?
No separate action runner for this row.
Lifecycle record
The current review found no separate hook or setup step for this base. Open the full record.
Prerequisites
8 prerequisites are declared for this base. Each prerequisite says whether it must be checked before render or before apply.
Next
Review chart analysis and create a recipe candidate
Reason
Promotion needs source and destination ConfigHub Spaces. It has not been tested for this configuration.
Helm outputPassedSaved in ConfigHubNot runLocal clusterNot runSetup stepNot neededGitOps and OCINot runLive Helm comparisonNot runTwo clustersNot runPromotionNot run
Prerequisites still apply. “Not needed” under Setup step means there is no separate hook or setup runner for this configuration; it does not remove the prerequisite listed above.
We ran cub check v0.7.3 against the exact rendered objects for every configuration below. The result is advisory: read each finding and decide whether it matters for your target.
8 advisory findings 3 critical, 4 warning, 1 info ClusterPolicy with empty rules causes panic Container does not set runAsNonRoot Container does not disable allowPrivilegeEscalation
13 advisory findings 3 critical, 7 warning, 3 info ClusterPolicy with empty rules causes panic Container does not set runAsNonRoot Container does not disable allowPrivilegeEscalation
13 advisory findings 3 critical, 7 warning, 3 info ClusterPolicy with empty rules causes panic Container does not set runAsNonRoot Container does not disable allowPrivilegeEscalation
13 advisory findings 3 critical, 7 warning, 3 info ClusterPolicy with empty rules causes panic Container does not set runAsNonRoot Container does not disable allowPrivilegeEscalation
8 advisory findings 3 critical, 4 warning, 1 info ClusterPolicy with empty rules causes panic Container does not set runAsNonRoot Container does not disable allowPrivilegeEscalation
13 advisory findings 3 critical, 7 warning, 3 info ClusterPolicy with empty rules causes panic Container does not set runAsNonRoot Container does not disable allowPrivilegeEscalation
13 advisory findings 3 critical, 7 warning, 3 info ClusterPolicy with empty rules causes panic Container does not set runAsNonRoot Container does not disable allowPrivilegeEscalation
What this does not check: hook execution, CRD readiness, target Secrets and cloud services, admission behavior, workload health, or rollback. The linked Catalog review covers chart-specific source and operating questions. ConfigHub validation and approval are separate managed controls.
Every reference below comes from the reviewed rendered output. What you see is what the cluster pulls. These references are data: you can change a registry or pin a digest with a recorded edit, and prove the change landed in every environment.
Base variant
Images
default
container-toolkit dcgm dcgm-exporter default: nvcr.io/nvidia/driver description: CC Manager image name description: GDRCopy driver image name description: GFD image name description: Image represents NVIDIA Driver Manager image description: Image represents NVIDIA Driver Manager image name description: Image represents image name description: Kata Manager image name description: NVIDIA Container Toolkit image name description: NVIDIA DCGM Exporter image name description: NVIDIA DCGM image name description: NVIDIA DRA driver image name description: NVIDIA Device Plugin image name description: NVIDIA Driver image name description: NVIDIA GDRCopy driver image name description: NVIDIA GPUDirect Storage Driver image name description: NVIDIA MIG Manager image name description: NVIDIA Sandbox Device Plugin image name description: NVIDIA component image name description: NVIDIA vGPU Device Manager image name description: NVIDIA vGPU Manager image name description: Node Status Exporter image name description: VFIO Manager image name description: Validator image name driver gdrdrv gpu-operator k8s-cc-manager k8s-device-plugin k8s-driver-manager k8s-mig-manager kubevirt-gpu-device-plugin nvcr.io/nvidia/gpu-operator:v26.7.1 nvidia-fs nvidia-sandbox-device-plugin registry.k8s.io/nfd/node-feature-discovery:v0.19.0 vgpu-device-manager vgpu-manager
aicr-eks-training
container-toolkit dcgm dcgm-exporter default: nvcr.io/nvidia/driver description: CC Manager image name description: GDRCopy driver image name description: GFD image name description: Image represents NVIDIA Driver Manager image description: Image represents NVIDIA Driver Manager image name description: Image represents image name description: Kata Manager image name description: NVIDIA Container Toolkit image name description: NVIDIA DCGM Exporter image name description: NVIDIA DCGM image name description: NVIDIA DRA driver image name description: NVIDIA Device Plugin image name description: NVIDIA Driver image name description: NVIDIA GDRCopy driver image name description: NVIDIA GPUDirect Storage Driver image name description: NVIDIA MIG Manager image name description: NVIDIA Sandbox Device Plugin image name description: NVIDIA component image name description: NVIDIA vGPU Device Manager image name description: NVIDIA vGPU Manager image name description: Node Status Exporter image name description: VFIO Manager image name description: Validator image name driver gdrdrv gpu-operator k8s-cc-manager k8s-device-plugin k8s-driver-manager k8s-mig-manager kubevirt-gpu-device-plugin nvcr.io/nvidia/gpu-operator:v26.7.1 nvidia-fs nvidia-sandbox-device-plugin vgpu-device-manager vgpu-manager
driver-580.105.08
container-toolkit dcgm dcgm-exporter default: nvcr.io/nvidia/driver description: CC Manager image name description: GDRCopy driver image name description: GFD image name description: Image represents NVIDIA Driver Manager image description: Image represents NVIDIA Driver Manager image name description: Image represents image name description: Kata Manager image name description: NVIDIA Container Toolkit image name description: NVIDIA DCGM Exporter image name description: NVIDIA DCGM image name description: NVIDIA DRA driver image name description: NVIDIA Device Plugin image name description: NVIDIA Driver image name description: NVIDIA GDRCopy driver image name description: NVIDIA GPUDirect Storage Driver image name description: NVIDIA MIG Manager image name description: NVIDIA Sandbox Device Plugin image name description: NVIDIA component image name description: NVIDIA vGPU Device Manager image name description: NVIDIA vGPU Manager image name description: Node Status Exporter image name description: VFIO Manager image name description: Validator image name driver gdrdrv gpu-operator k8s-cc-manager k8s-device-plugin k8s-driver-manager k8s-mig-manager kubevirt-gpu-device-plugin nvcr.io/nvidia/gpu-operator:v26.7.1 nvidia-fs nvidia-sandbox-device-plugin registry.k8s.io/nfd/node-feature-discovery:v0.19.0 vgpu-device-manager vgpu-manager
driver-580.126.20
container-toolkit dcgm dcgm-exporter default: nvcr.io/nvidia/driver description: CC Manager image name description: GDRCopy driver image name description: GFD image name description: Image represents NVIDIA Driver Manager image description: Image represents NVIDIA Driver Manager image name description: Image represents image name description: Kata Manager image name description: NVIDIA Container Toolkit image name description: NVIDIA DCGM Exporter image name description: NVIDIA DCGM image name description: NVIDIA DRA driver image name description: NVIDIA Device Plugin image name description: NVIDIA Driver image name description: NVIDIA GDRCopy driver image name description: NVIDIA GPUDirect Storage Driver image name description: NVIDIA MIG Manager image name description: NVIDIA Sandbox Device Plugin image name description: NVIDIA component image name description: NVIDIA vGPU Device Manager image name description: NVIDIA vGPU Manager image name description: Node Status Exporter image name description: VFIO Manager image name description: Validator image name driver gdrdrv gpu-operator k8s-cc-manager k8s-device-plugin k8s-driver-manager k8s-mig-manager kubevirt-gpu-device-plugin nvcr.io/nvidia/gpu-operator:v26.7.1 nvidia-fs nvidia-sandbox-device-plugin registry.k8s.io/nfd/node-feature-discovery:v0.19.0 vgpu-device-manager vgpu-manager
external-nfd
container-toolkit dcgm dcgm-exporter default: nvcr.io/nvidia/driver description: CC Manager image name description: GDRCopy driver image name description: GFD image name description: Image represents NVIDIA Driver Manager image description: Image represents NVIDIA Driver Manager image name description: Image represents image name description: Kata Manager image name description: NVIDIA Container Toolkit image name description: NVIDIA DCGM Exporter image name description: NVIDIA DCGM image name description: NVIDIA DRA driver image name description: NVIDIA Device Plugin image name description: NVIDIA Driver image name description: NVIDIA GDRCopy driver image name description: NVIDIA GPUDirect Storage Driver image name description: NVIDIA MIG Manager image name description: NVIDIA Sandbox Device Plugin image name description: NVIDIA component image name description: NVIDIA vGPU Device Manager image name description: NVIDIA vGPU Manager image name description: Node Status Exporter image name description: VFIO Manager image name description: Validator image name driver gdrdrv gpu-operator k8s-cc-manager k8s-device-plugin k8s-driver-manager k8s-mig-manager kubevirt-gpu-device-plugin nvcr.io/nvidia/gpu-operator:v26.7.1 nvidia-fs nvidia-sandbox-device-plugin vgpu-device-manager vgpu-manager
preinstalled-driver
container-toolkit dcgm dcgm-exporter default: nvcr.io/nvidia/driver description: CC Manager image name description: GDRCopy driver image name description: GFD image name description: Image represents NVIDIA Driver Manager image description: Image represents NVIDIA Driver Manager image name description: Image represents image name description: Kata Manager image name description: NVIDIA Container Toolkit image name description: NVIDIA DCGM Exporter image name description: NVIDIA DCGM image name description: NVIDIA DRA driver image name description: NVIDIA Device Plugin image name description: NVIDIA Driver image name description: NVIDIA GDRCopy driver image name description: NVIDIA GPUDirect Storage Driver image name description: NVIDIA MIG Manager image name description: NVIDIA Sandbox Device Plugin image name description: NVIDIA component image name description: NVIDIA vGPU Device Manager image name description: NVIDIA vGPU Manager image name description: Node Status Exporter image name description: VFIO Manager image name description: Validator image name driver gdrdrv gpu-operator k8s-cc-manager k8s-device-plugin k8s-driver-manager k8s-mig-manager kubevirt-gpu-device-plugin nvcr.io/nvidia/gpu-operator:v26.7.1 nvidia-fs nvidia-sandbox-device-plugin registry.k8s.io/nfd/node-feature-discovery:v0.19.0 vgpu-device-manager vgpu-manager
preinstalled-driver-and-toolkit
container-toolkit dcgm dcgm-exporter default: nvcr.io/nvidia/driver description: CC Manager image name description: GDRCopy driver image name description: GFD image name description: Image represents NVIDIA Driver Manager image description: Image represents NVIDIA Driver Manager image name description: Image represents image name description: Kata Manager image name description: NVIDIA Container Toolkit image name description: NVIDIA DCGM Exporter image name description: NVIDIA DCGM image name description: NVIDIA DRA driver image name description: NVIDIA Device Plugin image name description: NVIDIA Driver image name description: NVIDIA GDRCopy driver image name description: NVIDIA GPUDirect Storage Driver image name description: NVIDIA MIG Manager image name description: NVIDIA Sandbox Device Plugin image name description: NVIDIA component image name description: NVIDIA vGPU Device Manager image name description: NVIDIA vGPU Manager image name description: Node Status Exporter image name description: VFIO Manager image name description: Validator image name driver gdrdrv gpu-operator k8s-cc-manager k8s-device-plugin k8s-driver-manager k8s-mig-manager kubevirt-gpu-device-plugin nvcr.io/nvidia/gpu-operator:v26.7.1 nvidia-fs nvidia-sandbox-device-plugin registry.k8s.io/nfd/node-feature-discovery:v0.19.0 vgpu-device-manager vgpu-manager
First-Run Caveats
Some chart paths need a small preparation step before the cub path feels as smooth as Helm. We show those steps here so the first run does not surprise you.
Caveat
What to do
Universal caveats
Use declared inputs or bases instead of Helm --set. For direct delivery, define pruning and field-conflict behavior. Use Argo CD or Flux when that controller path and its pruning settings are recorded for the selected preset.
Shared placeholder password
No shared placeholder password caveat recorded for this chart.
CRD first-ordering
Yes. 8 CRDs must exist first. The public package contains the bootstrap, and its generated try.sh applies it and waits for the CRDs before installing the main objects.
Did this version run on a local Kubernetes cluster?
Not checked
No linked result
Did an OCI delivery through GitOps run?
Not checked
No linked result
Did Helm and ConfigHub reach the same live result?
Not checked
No linked result
Was the result compared on separate clusters?
Not checked
No linked result
Was a ConfigHub promotion tested?
Not checked
No linked result
Did this version string point at changed upstream bytes?
Not checked
No linked result
How much is proven, and what more testing would add: Fully proven: Render parity. Not yet tested: ConfigHub proof, Local live, GitOps/OCI live, Live Helm-vs-ConfigHub, Two-cluster kind - a fresh cluster run would prove these.
Base
Readiness
Render
ConfigHub
Local live
GitOps/OCI
Live parity
Two-cluster kind
default
real
yes
todo
todo
todo
todo
todo
aicr-eks-training
real
yes
todo
todo
todo
todo
todo
driver-580.105.08
real
yes
todo
todo
todo
todo
todo
driver-580.126.20
real
yes
todo
todo
todo
todo
todo
external-nfd
real
yes
todo
todo
todo
todo
todo
preinstalled-driver
real
yes
todo
todo
todo
todo
todo
preinstalled-driver-and-toolkit
real
yes
todo
todo
todo
todo
todo
What You Must Provide
exact rendered objects with render parity and receipts
Field
Value
Known quirks
None flagged
You must provide
nothing beyond a cluster and namespace
What ConfigHub records
exact rendered objects with render parity and receipts
Optional chart inputs
None identified in the chart facts
How optional inputs are handled
No handling rule is recorded
Hooks, CRDs, And Setup Work
Some Helm charts need work before, during, or after apply: CRDs, hooks, setup jobs, webhook certificates, migrations, generated Secrets, or checks. For each chart, the catalog should make the choice clear: include it in the base variant, split it into a separate base variant, run a setup step, use a GitOps action where evidence exists, require an existing target resource, or block it when there is no safe default.
What each base needs before apply
These requirements come from the same base definition as the rendered objects. The render intent keeps the chart inputs, required Secrets or CRDs, lifecycle steps, and evidence together.
Base variant
Required resource
How to provide it
Full record
default
8 CRDs
Included in the OCI package as prerequisites/target-facts/default-crds.yaml. It applies missing CRDs server-side. The generated try script leaves existing CRDs under their current owner and waits for them before the workload.
Included in the OCI package as prerequisites/target-facts/aicr-eks-training-crds.yaml. It applies missing CRDs server-side. The generated try script leaves existing CRDs under their current owner and waits for them before the workload.
Included in the OCI package as prerequisites/target-facts/driver-580-105-08-crds.yaml. It applies missing CRDs server-side. The generated try script leaves existing CRDs under their current owner and waits for them before the workload.
Included in the OCI package as prerequisites/target-facts/driver-580-126-20-crds.yaml. It applies missing CRDs server-side. The generated try script leaves existing CRDs under their current owner and waits for them before the workload.
Included in the OCI package as prerequisites/target-facts/external-nfd-crds.yaml. It applies missing CRDs server-side. The generated try script leaves existing CRDs under their current owner and waits for them before the workload.
Included in the OCI package as prerequisites/target-facts/preinstalled-driver-crds.yaml. It applies missing CRDs server-side. The generated try script leaves existing CRDs under their current owner and waits for them before the workload.
Included in the OCI package as prerequisites/target-facts/preinstalled-driver-and-toolkit-crds.yaml. It applies missing CRDs server-side. The generated try script leaves existing CRDs under their current owner and waits for them before the workload.
If no plan is shown, that does not prove the upstream chart has no hooks. It means the public catalog has no chart-specific action to show yet; check the matrix or send a problem chart if hook behavior should be modeled. Direct apply, Argo CD, Flux, and upgrade implementations are tracked separately. One passing implementation does not prove the others.
No chart-specific action is attached to this page yet. That is not a claim that the upstream chart has no hooks or setup work. It means the public catalog has no per-chart-base variant action to show here; check the catalog filters, the matrix, or send a problem chart if hook behavior should be modeled.
Before Production
A green render or local live result is not a production support claim. Production support is target-scoped and uses the support-decision artifact when present.
Field
Value
Production review status
Not reviewed for production
Target-scoped support decision
not recorded
Supported base
Target scope
Accepted limits
None recorded
Open policy decisions
None recorded for this policy checklist
Next action
review chart analysis and create a recipe candidate
The plain-objects script applies the objects and ends. It does not wait for the workloads to start. Neither script runs the steps the plan names for an upgrade or a delete. A cluster with no GPUs shows that the objects apply. It does not show the workload using a GPU.