Expected Results And Clusters

UNOFFICIAL/EXPERIMENTAL

Every guide should show what the user should see after the command they just ran. The default path should not make a new user read proof machinery first. Use this page as the simple checking pattern for the public guides.

Short Version

The Default UX Should Be Product Commands First

For a new user, the steel thread is:

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.

choose chart
-> render with cub installer
-> inspect what was produced
-> optionally upload to ConfigHub
-> optionally apply or deliver
-> verify the specific thing they just did

npm run ... commands are optional proof checks. They are useful for reviewers, maintainers, CI, and users who want to verify a receipt. They should not be the main product action in a default guide unless the guide is explicitly about proof or parity.

Stage 1: Serverless Redis Render

Run:

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 oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-redis:25.5.3 \
  --base reuse-existing-secret \
  --work-dir ./redis-reuse-existing-secret \
  --non-interactive \
  --namespace redis

You should see a completed work directory.

Check:

find ./redis-reuse-existing-secret/out -maxdepth 2 -type f | sort | head

You should see something like:

./redis-reuse-existing-secret/out/manifests/...

The recommended Redis preset does not ship a password. It expects a Secret named redis-existing-secret. Create that prerequisite before a local apply:

kubectl create namespace redis --dry-run=client -o yaml | kubectl apply -f -
kubectl -n redis create secret generic redis-existing-secret \
  --from-literal=redis-password="$(openssl rand -base64 32)"
kubectl apply -f ./redis-reuse-existing-secret/out/manifests

The Redis chart page carries the catalog evidence for this base. You do not need to run the repository proof harness for the first pass through the guide.

Stage 2: Standard Helm Baseline

If the guide asks you to compare with standard Helm, use the same chart version and values as the catalog base. Use a separate namespace or a separate throwaway cluster so the two installs do not collide. A naked helm install can be a useful smoke test, but it is not a parity check unless the inputs match.

Example shape:

kubectl create namespace helm-redis --dry-run=client -o yaml | kubectl apply -f -
kubectl -n helm-redis create secret generic redis-existing-secret \
  --from-literal=redis-password="$(openssl rand -base64 32)"
helm install redis oci://registry-1.docker.io/bitnamicharts/redis \
  --version 25.5.3 \
  --namespace helm-redis \
  -f recipes/bitnami/redis/25.5.3/effective-values-reuse-existing-secret.yaml

You should see Helm create a release:

NAME: redis
LAST DEPLOYED: ...
NAMESPACE: helm-redis
STATUS: deployed

Then check Kubernetes:

kubectl -n helm-redis get statefulset,pod,pvc

You should see Redis StatefulSets, pods, and PVCs. Some charts take time to become ready; readiness is a live-cluster fact, not a render fact.

For strict parity, use two clean clusters rather than comparing namespaces by eye. Install regular Helm into one cluster. Render with cub installer and apply the output into the other. Then compare the live Kubernetes objects and workload readiness. The repository has a harness that automates this for maintainers; that harness is not the default user install path.

Stage 3: Upload To ConfigHub

Run:

cub installer upload \
  --work-dir ./redis-reuse-existing-secret \
  --space helm-redis-existing-secret \
  --component Redis \
  --layer App \
  --environment Demo \
  --owner ConfigHubHelm \
  --variant reuse-existing-secret \
  --unit-label Component=Redis \
  --unit-label HelmChart=bitnami-redis \
  --unit-label HelmChartVersion=25.5.3 \
  --unit-label Variant=reuse-existing-secret

Then check:

cub unit list --space helm-redis-existing-secret \
  --columns Unit.Slug,Unit.Labels.Component,Unit.Labels.Variant

You should see Redis Units, all labeled with Component=Redis and Variant=reuse-existing-secret. Expect the Kubernetes objects plus an installer-record Unit. The external Secret is not uploaded.

In the ConfigHub UI:

Space helm-redis-existing-secret -> Units

You should see the same Units and labels. If you want to rerun the repository proof harness, use Verify It Yourself after the product path is clear.

Stage 4: Local Kubernetes

Users may bring any reachable Kubernetes cluster. For quick local tests, use a throwaway kind cluster:

kind create cluster --name helm-expt-demo
kubectl config use-context kind-helm-expt-demo

Create the required Secret, then apply the rendered manifests:

kubectl create namespace redis --dry-run=client -o yaml | kubectl apply -f -
kubectl -n redis create secret generic redis-existing-secret \
  --from-literal=redis-password="$(openssl rand -base64 32)"
kubectl apply -f ./redis-reuse-existing-secret/out/manifests

Then check:

kubectl -n redis get statefulset,pod,pvc

You should see Redis workloads and PVCs. A healthy Redis run should eventually show pods in Running or Ready state.

For deeper checks, use kubectl describe, workload logs, or a cub-scout receipt. The repository proof harness can also check Redis-specific behavior, but it should not be the first thing a new user has to understand.

Stage 5: Argo CD, Flux, And cub cluster

For GitOps examples, users need a cluster that already has the chosen controller and the ConfigHub OCI pull credentials. There are two sensible paths:

The important point is that ConfigHub does not replace the in-cluster controller in the GitOps path. ConfigHub stores Units, publishes one OCI artifact, and records evidence. Argo or Flux pulls and reconciles it.

You should verify two things:

controller accepted the artifact
workloads reached the expected live state

A synced controller alone is not enough. Read Why Synced Is Not Working.

Stage 6: Apps And Ops

After upload, the expected checks become ConfigHub checks:

For a user guide, each step should show one concrete check:

cub unit list ...
cub variant promote ... --dry-run
kubectl get ...
controller status page
ConfigHub Space -> Units
ConfigHub changeset / approval / receipt

Existing Apps, Platforms, Stacks, And Live Clusters

Yes, an existing app can enter the model. That is not the same as starting from a public catalog chart.

The first expected result should be read-only:

ConfigHub found the app
ConfigHub shows the objects
no cluster change was made yet
next action is import, variant, or recipe graduation

Only move to a cub installer recipe when the app needs a maintained render path, future chart refreshes, and catalog-grade proof.

What Not To Put In The Default Guide Path

Do not make a new user run the full repo gate just to understand the product. Use it for broad repo verification before release or review. In a user guide, prefer a visible check tied to the thing they just did:

The default UX should stay simple. The proof machinery is there when the user asks, "how do I know?"