open-telemetry/opentelemetry-operator 0.114.0

What it is. open-telemetry/opentelemetry-operator 0.114.0, as 17 Kubernetes objects in its default preset. The Catalog holds 2 presets of this version.

Install it. Use its installer package with cub installer. The five steps below give the commands.

How it works. How the model works, and Helm in the Catalog.

What this page gives you

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.

Most choices are made before you install

The package fixes and checks almost everything at build time. What you set is small and typed.

You can read the test results

Open the saved results for the Helm comparison, live install, and delivery checks.

See hooks, CRDs, and setup work

The page names the work and says which delivery path has actually run.

What To Use

default configuration: 17 rendered objects · 3 images · 3 target prerequisites · 0 hook or setup steps · 3/4 checks passing. These counts come from the linked test records.

defaultFirst recorded base variant

2Candidate base variants

Review before useFirst-configuration status

Not reviewed for productionProduction status

The recipe/package proof exists and useful variants exist, but this chart has not been promoted into the public catalog.

Question	Answer
Catalog readiness	Review before use
Chart version	0.114.0
Exact installer package	`oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/open-telemetry-opentelemetry-operator:0.114.0@sha256:b6e1298c04526648e5e182fffb70d7fefe40d7809dc400699acb3e3f73abaa24`
OCI publication status	publication receipt recorded
Publisher signature	publisher signature recorded and verified
Latest upstream seen	not checked
Candidate base variants	default;no-crds
Not yet available	No specific missing capability is recorded. The first configuration still needs review.
Namespace	default

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.	Destination access: yes Selected configuration deployed: yes	Not run no run recorded

Open the complete assessment, source, lifecycle, and evidence record.

Where This Chart's Settings Come From

Base variant	Helm values	ConfigHub changes	Install work
default	effective-values.yaml	None in the catalog base. Later edits appear in ConfigHub Unit revision history or a derived variant.	3 prerequisites recorded.
no-crds	effective-values-no-crds.yaml	None in the catalog base. Later edits appear in ConfigHub Unit revision history or a derived variant.	7 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.

Read the full values-versus-ConfigHub rule. For the staging commands behind each prerequisite, open the prerequisite action packets.

What This Chart Contains

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 31 files.

Construct	Found	Why it matters when a chart ships as plain YAML
Helm hooks	4	Hook Jobs never fire, or fire under a different hook dialect.
Cluster lookups	2	The chart reads the cluster while rendering, so a render without one is valid but wrong.
Webhook configuration	4	An empty certificate bundle makes admission fail closed.
Capability branching	3	The chart chooses apiVersions from the cluster it renders against.
Generated credentials	3	Every render mints new values, and a shared artifact would freeze one draw.
Custom resource definitions	4	Per-file delivery can race the definitions the resources depend on.
Test hooks	3	Test resources would ship to a cluster that never asked for them.

A flattening-safety verdict has decided this version: default:unsafe-to-flatten; no-crds:unsafe-to-flatten. 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.

Key	Where to look first	What it means
Package users pull	`oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/open-telemetry-opentelemetry-operator:0.114.0@sha256:b6e1298c04526648e5e182fffb70d7fefe40d7809dc400699acb3e3f73abaa24`	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	Secret default/opentelemetry-operator-controller-manager-service-cert keys tls.crt,tls.key `Run cert-manager controller to satisfy the chart-rendered Certificate, or stage a valid TLS Secret before waiting for the operator` 2 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.
Kubernetes objects	full rendered YAML	The full YAML captured from this base variant. It is the output of the render.
Render record	default render intent	The Helm inputs and evidence links that explain how the output was produced.
Complete starting record	default base-variant record	The record that connects the Helm inputs, Kubernetes objects, remaining requirements, setup work, checks, and OCI status.
Hooks, CRDs, and setup work	this page's setup section	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.

How render intents work · All generated render intents · All base variant records

Try This Chart

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/open-telemetry-opentelemetry-operator:0.114.0@sha256:b6e1298c04526648e5e182fffb70d7fefe40d7809dc400699acb3e3f73abaa24
publication receipt recorded · open the exact publication receipt

Readable version tag: oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/open-telemetry-opentelemetry-operator:0.114.0. 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.

Check the package identity

cub installer inspect oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/open-telemetry-opentelemetry-operator:0.114.0@sha256:b6e1298c04526648e5e182fffb70d7fefe40d7809dc400699acb3e3f73abaa24 --json

Read how each configuration was made

cub installer pull 'oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/open-telemetry-opentelemetry-operator:0.114.0@sha256:b6e1298c04526648e5e182fffb70d7fefe40d7809dc400699acb3e3f73abaa24' --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.

cosign verify --certificate-identity helm-expt-package-signer@nth-fort-499605-q5.iam.gserviceaccount.com --certificate-oidc-issuer https://accounts.google.com --annotations confighub.com/package-path=packages/open-telemetry/opentelemetry-operator/0.114.0 --annotations confighub.com/package-sha256=f67492edf6f1b7906412374dd5897622b37569e016edb34b105f3e7cb3cf780e europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/open-telemetry-opentelemetry-operator:0.114.0@sha256:b6e1298c04526648e5e182fffb70d7fefe40d7809dc400699acb3e3f73abaa24

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.

Signature receipt · Sigstore bundle · How signature verification works

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.

First recorded command

cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/open-telemetry-opentelemetry-operator:0.114.0@sha256:b6e1298c04526648e5e182fffb70d7fefe40d7809dc400699acb3e3f73abaa24 --base default --work-dir ./open-telemetry-opentelemetry-operator-0-114-0-default --non-interactive --namespace default

Advanced: apply it or upload it

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: Gitops runtime: Argo health Progressing (parity passed)

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 2 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 0.114.0

What 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 open-telemetry/opentelemetry-operator
version is 0.114.0
base is default
valuesProfile is recipes/open-telemetry/opentelemetry-operator/0.114.0/effective-values.yaml
namespace is default
releaseName is opentelemetry-operator
capabilityProfile is {"apiVersions":[],"kubeVersion":"1.30.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.

cert-manager Certificate CRD required by the chart-rendered serving certificate object. Install cert-manager or apply the cert-manager Certificate CRD before applying this base Declared. Not checked on any destination.
cert-manager Issuer CRD required by the chart-rendered self-signed issuer object. Install cert-manager or apply the cert-manager Issuer CRD before applying this base Declared. Not checked on any destination.
Webhook serving certificate Secret mounted by the operator Deployment. Run cert-manager controller to satisfy the chart-rendered Certificate, or stage a valid TLS Secret before waiting for the operator Declared. Not checked on any destination.

This entry's plan, and how to test it

The record lists no plan step for this entry.

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.

Compared with plain Helm. The Catalog installed this base beside plain Helm on two local clusters, and the two matched. Read the receipt.

Read what a plan is, and why some entries have one.

1. Get the exact objects Run for this entry

The Catalog rendered this entry and retains its 17 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 open-telemetry-opentelemetry-operator-0-114-0-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/open-telemetry/opentelemetry-operator/0.114.0/revisions/default/r001/rendered/release-objects.yaml

# check the bytes against the listing
$ shasum -a 256 open-telemetry-opentelemetry-operator-0-114-0-default.yaml
68dd01565796d137e5dea26e1db02ef3e0d99bbbafd000ec3663680b5bbda873  open-telemetry-opentelemetry-operator-0-114-0-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/open-telemetry-opentelemetry-operator:0.114.0@sha256:b6e1298c04526648e5e182fffb70d7fefe40d7809dc400699acb3e3f73abaa24 --base default --work-dir ./open-telemetry-opentelemetry-operator-0-114-0-default --non-interactive --namespace default

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 one other base in the Catalog, no-crds.

# fetch the no-crds base of the same version
$ curl -fsSL -o open-telemetry-opentelemetry-operator-0-114-0-no-crds.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/open-telemetry/opentelemetry-operator/0.114.0/revisions/no-crds/r001/rendered/release-objects.yaml

# list what differs between the two bases
$ cub config diff open-telemetry-opentelemetry-operator-0-114-0-default.yaml open-telemetry-opentelemetry-operator-0-114-0-no-crds.yaml --summary

3. Upload it as a variant Run for this entry

The Catalog saved this entry in ConfigHub. The commands use its signed installer package. Read the log of the live walk on 2026-10-08 · Read the record that states this.

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 ./open-telemetry-opentelemetry-operator-0-114-0-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 listing records 3 inputs that the destination must supply, so read them before you deploy. 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 Partly run for this entry

A promotion ran for this entry. It ran the preview and the promote. The delete and the publish below have no recorded run 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 · Read the record that states this.

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 no-crds, version 0.114.0

What 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 open-telemetry/opentelemetry-operator
version is 0.114.0
base is no-crds
valuesProfile is recipes/open-telemetry/opentelemetry-operator/0.114.0/effective-values-no-crds.yaml
namespace is default
releaseName is opentelemetry-operator
capabilityProfile is {"apiVersions":[],"kubeVersion":"1.30.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.

cert-manager Certificate CRD required by the chart-rendered serving certificate object. Install cert-manager or apply the cert-manager Certificate CRD before applying this base Declared. Not checked on any destination.
cert-manager Issuer CRD required by the chart-rendered self-signed issuer object. Install cert-manager or apply the cert-manager Issuer CRD before applying this base Declared. Not checked on any destination.
OpenTelemetry Operator CRD managed outside this no-crds base. Apply the default base CRDs or install the OpenTelemetry Operator CRDs before applying this base Declared. Not checked on any destination.
OpenTelemetry Operator CRD managed outside this no-crds base. Apply the default base CRDs or install the OpenTelemetry Operator CRDs before applying this base Declared. Not checked on any destination.
OpenTelemetry Operator CRD managed outside this no-crds base. Apply the default base CRDs or install the OpenTelemetry Operator CRDs before applying this base Declared. Not checked on any destination.
OpenTelemetry Operator CRD managed outside this no-crds base. Apply the default base CRDs or install the OpenTelemetry Operator CRDs before applying this base Declared. Not checked on any destination.
Webhook serving certificate Secret mounted by the operator Deployment. Run cert-manager controller to satisfy the chart-rendered Certificate, or stage a valid TLS Secret before waiting for the operator Declared. Not checked on any destination.

This entry's plan, and how to test it

The record lists no plan step for this entry.

Compared with plain Helm. The Catalog installed this base beside plain Helm on two local clusters, and the two matched. Read the receipt.

Read what a plan is, and why some entries have one.

1. Get the exact objects Run for this entry

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 open-telemetry-opentelemetry-operator-0-114-0-no-crds.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/open-telemetry/opentelemetry-operator/0.114.0/revisions/no-crds/r001/rendered/release-objects.yaml

# check the bytes against the listing
$ shasum -a 256 open-telemetry-opentelemetry-operator-0-114-0-no-crds.yaml
6ca1e737e9540f4b6a2d6e19fa83fa580cb407942b78ed53f9604aa46b662ea1  open-telemetry-opentelemetry-operator-0-114-0-no-crds.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/open-telemetry-opentelemetry-operator:0.114.0@sha256:b6e1298c04526648e5e182fffb70d7fefe40d7809dc400699acb3e3f73abaa24 --base no-crds --work-dir ./open-telemetry-opentelemetry-operator-0-114-0-no-crds --non-interactive --namespace default

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 one other base in the Catalog, default.

# fetch the default base of the same version
$ curl -fsSL -o open-telemetry-opentelemetry-operator-0-114-0-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/open-telemetry/opentelemetry-operator/0.114.0/revisions/default/r001/rendered/release-objects.yaml

# list what differs between the two bases
$ cub config diff open-telemetry-opentelemetry-operator-0-114-0-no-crds.yaml open-telemetry-opentelemetry-operator-0-114-0-default.yaml --summary

3. Upload it as a variant Run for this entry

The Catalog saved this entry in ConfigHub. The commands use its signed installer package. Read the log of the live walk on 2026-10-08 · Read the record that states this.

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.

# 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 ./open-telemetry-opentelemetry-operator-0-114-0-no-crds --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 listing records 7 inputs that the destination must supply, so read them before you deploy. The coverage lanes record a GitOps OCI run for this base. They are separate from the delivery record this step reads. Read the log of the live walk on 2026-10-08.

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.

# 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 Partly run for this entry

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

For agentsThese steps are the nextSteps array of open-telemetry-opentelemetry-operator-0-114-0-default.json, open-telemetry-opentelemetry-operator-0-114-0-no-crds.json. Each state was read from flattened.retainedObjects, flattened.inventory, source.ociRef, oci.bundles, oci.runtimes, lifecycle.promotion, lifecycle.coverage and variants.known in the same listing. A command marked needsAccount there contacts ConfigHub. A step's notes hold its cautions, carries lists the CRDs the base brings, and liveWalk links the dated log that ran its commands.

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.

Job	Next step
Render and inspect without applying	Run the recommended `cub installer setup` command above.
Run shared local configuration checks	`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	Publish reviewed objects as OCI or apply the manifests with kubectl.
Save the reviewed result for a team	Save and upload the reviewed result to ConfigHub for shared history, exact diffs, and approvals.
Compare development and production, audit an exact diff, promote, or roll back	Build a promotion review or read the bounded rollback example.
Assign the configuration to clusters and operate a small fleet	Choose targets, preview a wave, and inspect every result.
Check delivery limits	Read the current limits before choosing kubectl, Argo CD, or Flux.
Handle CRDs on the first install	Read the CRD ordering risk and first-install guide, then check this chart's recorded owner and plan.

Available Configurations

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.

3 matrix rows for open-telemetry/opentelemetry-operator@0.114.0 · open the full matrix

F1 · Source chart

(source)

Source

Pinned upstream chart and version

Status: Available in the catalog
How to run: This is the upstream chart source. Choose a base card below before running the installer.
Evidence: Pinned chart source and dependency lock
Hooks/actions: No separate hook or action for this row.
Who runs actions?: No separate action runner for this row.
Next: Choose a chart configuration before rendering or deploying
Reason: This is the chart source. Choose a configuration before checking deployment or promotion

Helm outputNot neededSaved in ConfigHubNot neededLocal clusterNot neededSetup stepNot neededGitOps and OCINot neededLive Helm comparisonNot neededTwo clustersNot neededPromotionNot needed

catalog · source repo

F2a · Chart default

default

Base

Runnable base variant made from the chart defaults

Status: Available in the catalog
Helm values: effective-values.yaml
ConfigHub changes: None in this catalog base. After upload, read Unit revision history or the derived variant.
How to run: cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/open-telemetry-opentelemetry-operator:0.114.0@sha256:b6e1298c04526648e5e182fffb70d7fefe40d7809dc400699acb3e3f73abaa24 --base default --work-dir ./open-telemetry-opentelemetry-operator-0-114-0-default --non-interactive --namespace default
Scripts: try.sh renders, settles the prerequisites in order, and applies with kubectl; confighub.sh renders and uploads to your ConfigHub Space.
Evidence: Live helm vs confighub parity
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: 3 prerequisites are declared for this base. Each prerequisite says whether it must be checked before render or before apply.
Next: Gitops runtime review
Reason: Gitops runtime: Argo health Progressing (parity passed)

Helm outputPassedSaved in ConfigHubPassedLocal clusterBlockedSetup stepNot neededGitOps and OCIReviewLive Helm comparisonReviewTwo clustersPassedPromotionPassed

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.

catalog · variant · full YAML · render intent · base record · package base · receipt · source repo

F2b · Helm-rendered base

no-crds

Base

Runnable base variant made with different Helm values

Status: Available in the catalog
Helm values: effective-values-no-crds.yaml
ConfigHub changes: None in this catalog base. After upload, read Unit revision history or the derived variant.
How to run: cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/open-telemetry-opentelemetry-operator:0.114.0@sha256:b6e1298c04526648e5e182fffb70d7fefe40d7809dc400699acb3e3f73abaa24 --base no-crds --work-dir ./open-telemetry-opentelemetry-operator-0-114-0-no-crds --non-interactive --namespace default
Scripts: try.sh renders, settles the prerequisites in order, and applies with kubectl; confighub.sh renders and uploads to your ConfigHub Space.
Evidence: Live helm vs confighub parity
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: 7 prerequisites are declared for this base. Each prerequisite says whether it must be checked before render or before apply.
Next: Run catalog promotion review
Reason: Promotion was tested and recorded in ConfigHub.

Helm outputPassedSaved in ConfigHubPassedLocal clusterBlockedSetup stepNot neededGitOps and OCIPassedLive Helm comparisonPassedTwo clustersPassedPromotionPassed

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.

catalog · variant · full YAML · render intent · base record · package base · receipt · source repo

Local Configuration Checks

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.

Scanner and ruleset identity

Pattern bundle: v0.7.3
Bundle manifest: sha256:0405f6ffe21e567adf5d6a732d181c7f228194920456d046b4338baeb14de1a8
Risk catalog: sha256:7ff79a126ad99bba2505fec8b2b7711c03f50eb362141128ec1c83e27a5036ba

Configuration	Advisory result	Exact input	Checked	Evidence
`default`	7 advisory findings 2 critical, 4 warning, 1 info ClusterRole grants nodes/proxy enabling Kubelet API RCE ClusterRoleBinding binds nodes/proxy ClusterRole to subjects Deployment containers omit resource limits	17 objects `sha256:b9f7661861dd2a654a2384527536c017b1259de8453962cfe5d5e5329c8a930a`	2026-09-16	Full `cub check` result Exact YAML Separate Catalog review
`no-crds`	7 advisory findings 2 critical, 4 warning, 1 info ClusterRole grants nodes/proxy enabling Kubelet API RCE ClusterRoleBinding binds nodes/proxy ClusterRole to subjects Deployment containers omit resource limits	13 objects `sha256:f9055a757966b9f33ac360a4266b703247946c5218392c7f0c9e5750dfff0cd2`	2026-09-16	Full `cub check` result Exact YAML Separate Catalog review

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.

Read all shared check results and the mapping to Catalog rules.

Images This Chart Pulls

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	`ghcr.io/open-telemetry/opentelemetry-operator/opentelemetry-operator:0.152.0` `properties:` `type: string`
no-crds	`ghcr.io/open-telemetry/opentelemetry-operator/opentelemetry-operator:0.152.0`

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. 2 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.

Open the all-chart adoption caveats · Helm to cub migration · cub deployment path

Advice And Current Status

Use this section to see which chart-specific guides apply, what you must provide, and what work remains.

Playbook	Why it applies
Live Parity	has live, GitOps/OCI, or two-cluster parity work

Question	Current answer
User status	Works with target prerequisites
Can I use it?	Tests and useful configurations exist, but the catalog review is not finished.
First base	no-crds
Exact installer package	`oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/open-telemetry-opentelemetry-operator:0.114.0@sha256:b6e1298c04526648e5e182fffb70d7fefe40d7809dc400699acb3e3f73abaa24`
Tests completed	Tests complete; ready for catalog review (render parity 2/2; Local live 0/2; Live parity 1/2)
Coverage	Partial
You must provide	an existing Secret for some bases (buildable - not yet run); a CRD ownership choice (crds vs no-crds base)
What the tools record	exact rendered objects with render parity and receipts; CRD handling split into explicit bases; optional chart inputs handled by reviewed base configurations
Next action	run catalog promotion review

The source data lives in chart skills and chart evidence router.

What Has Been Tested

Choose the question you care about. Not checked means this catalog has no version-specific result; it is not a pass.

Question	Status	Evidence
Can I pull these exact package bytes again?	Checked	Package receipt
What does this chart contain?	Partly checked	Source lock · Chart guide · Render result · All 6 evidence links
Does the recorded render match Helm?	Checked	Render result 1 · Render record · Render result 2 · All 4 evidence links
Did the supplied values change the render?	Not checked	No linked result
Were hooks, CRDs, or setup steps checked?	Not applicable	No linked result
Did this version run on a local Kubernetes cluster?	Not checked	No linked result
Did an OCI delivery through GitOps run?	Partly checked	Version results below
Did Helm and ConfigHub reach the same live result?	Partly checked	Live comparison 1 · Live comparison 2
Was the result compared on separate clusters?	Checked	Version results below
Was a ConfigHub promotion tested?	Checked	Promotion receipt 1 · Promotion receipt 2
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, ConfigHub proof, Two-cluster kind. Proven on some bases: GitOps/OCI live, Live Helm-vs-ConfigHub. Not yet tested: Local live - a fresh cluster run would prove these.

Base	Readiness	Render	ConfigHub	Local live	GitOps/OCI	Live parity	Two-cluster kind
default	real	yes	yes	no	watch	watch	yes
no-crds	real	yes	yes	no	yes	yes	yes

What We Tested On A Cluster

This is the result of a real run for one base variant on one recorded target setup. It does not silently extend the result to other bases or clusters.

Question	Recorded answer
Base variant	no-crds
Target used	cub-managed kind proof cluster with target profile kind-cert-manager; installed from jetstack/cert-manager@v1.20.2/crds-enabled
Observed result	pass
What passed	regular Helm reached readiness ConfigHub direct apply reached readiness ConfigHub published the workload Space and cluster Space as OCI releases ConfigHub OCI/Argo synced all rendered Units and reported Healthy the OpenTelemetry Operator Deployment reached readiness the chart's Issuer and Certificate were reconciled by cert-manager semantic object parity passed with zero object diffs for direct apply and OCI/Argo
What the result means	The earlier watch was caused by a missing target prerequisite, not by a render difference.
Earlier result	On a plain kind target without a cert-manager controller, the operator ran but Argo remained Progressing because the chart's Certificate was never reconciled.
What this does not prove	This row does not prove OpenTelemetry Operator production support for arbitrary targets. This row does not prove the default base or a target without cert-manager. This row does not prove long-term certificate rotation or webhook certificate renewal.
Full review and receipt	Open the runtime review · open the live receipt

What You Must Provide

exact rendered objects with render parity and receipts; CRD handling split into explicit bases; optional chart inputs handled by reviewed base configurations

Field	Value
Known quirks	Crds; Existing secret; optional chart inputs
You must provide	an existing Secret for some bases (buildable - not yet run); a CRD ownership choice (crds vs no-crds base)
What ConfigHub records	exact rendered objects with render parity and receipts; CRD handling split into explicit bases; optional chart inputs handled by reviewed base configurations
Optional chart inputs	Tpl powered values
How optional inputs are handled	Keep empty in supported bases; Or make a reviewed installer base when populated

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	Secret default/opentelemetry-operator-controller-manager-service-cert keys tls.crt,tls.key	`Run cert-manager controller to satisfy the chart-rendered Certificate, or stage a valid TLS Secret before waiting for the operator`	full render intent
default	2 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.	full render intent
no-crds	Secret default/opentelemetry-operator-controller-manager-service-cert keys tls.crt,tls.key	`Run cert-manager controller to satisfy the chart-rendered Certificate, or stage a valid TLS Secret before waiting for the operator`	full render intent
no-crds	6 CRDs	Included in the OCI package as `prerequisites/target-facts/no-crds-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.	full render intent

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	run catalog promotion review

Source And Evidence Files

Artifact	Path
Chart catalog	recipes/open-telemetry/opentelemetry-operator/0.114.0/CATALOG.md
Machine-readable listing (default)	site/listings/open-telemetry-opentelemetry-operator-0-114-0-default.json
Machine-readable listing (no-crds)	site/listings/open-telemetry-opentelemetry-operator-0-114-0-no-crds.json
Helm render intents	data/helm-render-intents/summary.md
Base variant records	data/base-variant-records/summary.md
First render intent	data/helm-render-intents/intents/open-telemetry-opentelemetry-operator-0-114-0-default.yaml
First base variant record	data/base-variant-records/records/open-telemetry-opentelemetry-operator-0-114-0-default.yaml
Full rendered YAML	recipes/open-telemetry/opentelemetry-operator/0.114.0/revisions/default/r001/rendered/release-objects.yaml
Recipe	recipes/open-telemetry/opentelemetry-operator/0.114.0/recipe.yaml
Package	packages/open-telemetry/opentelemetry-operator/0.114.0
Installer OCI package catalog	data/installer-oci-packages/summary.md
Installer OCI publication receipt	runs/installer-oci/open-telemetry-opentelemetry-operator/0.114.0/installer-package-publication-receipt.yaml
Helm pain report	recipes/open-telemetry/opentelemetry-operator/0.114.0/helm-pain-report.yaml
Production review records	data/production-disposition/summary.md
Master matrix rows	data/master-catalog-matrix/summary.md
Chart skills	data/chart-skills/summary.md
Chart evidence router	data/chart-evidence-router/summary.md
Current test status	docs/user/current-proof-status.md
Cluster runtime review	recipes/open-telemetry/opentelemetry-operator/0.114.0/gitops-runtime-review.yaml

Technical notes and disclaimers

The script does not run the steps the plan names for an upgrade or a delete.
The Catalog publishes no plain objects for this entry, because its verdict is unsafe-to-flatten. It has no plain-objects test.