FAQ: Hard Questions Before You Trust The Catalog

UNOFFICIAL/EXPERIMENTAL

This page is for a skeptical Helm user, platform engineer, or reviewer. It answers the questions that should be asked before using the public catalog or moving a chart into ConfigHub-managed operations.

Questions that still need product work are tracked in P1: hard-questions-for-later FAQ backlog.

Is this just Helm with extra paperwork?

No. Helm still renders. The catalog turns selected render paths into durable cub installer packages with named bases, exact objects, scans, receipts, live evidence, and ConfigHub Units when uploaded.

Use Helm directly when you only need one render. Upload the rendered files separately only when you want ConfigHub Units:

New to cub? Install the cub CLI first. You can pull and render public catalog packages without an account. Commands that save or change ConfigHub data require you to sign in.

helm template <release> <chart> --values values.yaml > rendered.yaml
cub variant upload --component <name> --variant base rendered.yaml

Use cub installer packages when you want a maintained base with receipts and proof:

What this command does. cub installer is a released, open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally. It does not apply those files to a cluster; use kubectl, Argo CD, or Flux for delivery. The generated scripts stop before doing any work when the plugin or kustomize is missing.

cub installer setup --pull <installer OCI ref> --base <base>

Public catalog pages show the installer package OCI ref for each chart version, so a real command uses --pull oci://..., not a checkout-local path. See Choosing Commands and Installer Package OCI Refs.

Do I have to rewrite my charts?

No. The point is to keep using public Helm charts where they are already the right source, then make selected install paths explicit, reviewable, variant-aware, and observable.

If the chart needs a better base, the base is produced by changing the Helm inputs and rerendering through the installer path. If the chart needs an environment, region, customer, target, gate, or observation refinement after upload, that belongs in ConfigHub as a derived variant.

See Why This Exists and Creating Variants.

Does it only work for easy charts?

No. Redis teaches the path, but kube-prometheus-stack is the serious chart example. It exercises CRDs, webhooks, RBAC, generated facts, extension slots, target prerequisites, upgrades, and live observations.

Render parity is only the baseline. The useful proof is that target facts and lifecycle prerequisites become explicit, staged, observed, and bounded.

See Serious Chart Proof.

What happens to Helm hooks?

Hooks are not treated as ordinary static YAML. A hook or hook-like behavior must be observed, routed, marked per-target, blocked, or refused.

A known route is not the same as automatic execution. The route tells a human, agent, or product surface what must happen and who owns it.

See Chart Hooks: What Happens? and Hook Lifecycle Strategy.

Where do Secrets and credentials live?

They should not be hidden inside ConfigHub by accident. The catalog separates generated Secrets, existing-Secret references, target facts, and runtime Secret lifecycle where the chart requires that distinction.

For Redis, for example, default preserves the generated-Secret install shape. reuse-existing-secret deliberately renders no Redis Secret and requires the target Secret to exist.

See Secret Lifecycle, the generated Secret Lifecycle data, and Target Prerequisites.

What if the cluster is the wrong shape?

Then a green render is not enough. Some charts need CRDs, Secrets, storage classes, cloud identity, multiple schedulable nodes, API capabilities, or controller behavior that a generic cluster does not provide.

The catalog should mark those as target prerequisites, target-fit decisions, watch rows, blocked rows, or per-target routes. Logstash HA needing three schedulable workers is a good example: the model should say the target shape is invalid, not pretend the chart failed generically.

See Target Prerequisites and Target Prerequisites Before Rerun.

What if a Helm upgrade caused a production crash?

The model helps by breaking the upgrade into stages:

old render
new render
object diff
blast-radius evidence
lifecycle checks
target prerequisites
gates
rehearsals
receipts

That reduces opaque upgrades. It does not promise crash-free production.

See Helm Upgrade Crash Example.

Can I bring my own values files or overlays?

Yes, but the route matters.

If a choice changes Helm inputs or object shape, it belongs in a new installer base or import path. Examples: CRDs on/off, storage mode, ingress shape, generated Secret versus existing Secret, wrapper chart values, or extension slots that render new objects.

If a choice refines an uploaded object set, it belongs in a derived ConfigHub variant. Examples: target, labels, approval gates, observation policy, links, or approved post-render field fills.

See Custom Overlays, Creating Variants, and Change Routing Before OCI.

Can I trust a green GitOps sync?

Not by itself. Sync means the controller accepted the desired state. Workload convergence, target prerequisites, controller-owned fields, and semantic parity need separate evidence.

See Why Synced Is Not Working.

What if I already use Argo, Flux, or KRM?

That is the expected production shape, not a reason to start over. The catalog separates desired objects, ConfigHub Units, OCI publication, GitOps controller health, and live workload evidence so those tools can stay in the path without being mistaken for the whole proof.

Existing apps can be discovered or imported as product work, but the repo must not claim that every live object has already been converted back into desired state.

See Adopting Existing Apps, Generative GitOps Fit, and Verification Lanes.

What is free and what needs ConfigHub?

Public catalog browsing, local render checks, and public package setup are free or low-friction. Private catalogs, teams, approvals, variants, promotions, fleet operations, and production responsibility are ConfigHub-managed.

See Product Support Tiers and the generated Journey page.

What should I do if this breaks on my chart?

Send the public chart and values that expose the problem:

Problem chart issue template

The expected response is a public fixture and one of these outcomes:

Where To Check The Current Truth