UNOFFICIAL/EXPERIMENTAL.
The rule is simple: do not treat a quiet wait as a single mystery. Break the operation into visible stages and record which stage is slow, passed, blocked, or still under watch.
What To Watch
Before upload or apply, note the object shape:
New to cub? Install the cub CLI first. Public catalog packages pull and render anonymously, and you sign in only once a command saves or changes ConfigHub data.
cub unit list --space <space>
kubectl --kubeconfig <kubeconfig> get all -ADuring cub installer upload, check that the ConfigHub Space and Units are appearing:
cub unit list --space <space>
cub unit tree --space <space>After cub release publish <space>, separate the published Release from cluster and GitOps progress:
cub unit list --space <space>
cub release list --space <space>
kubectl --kubeconfig <kubeconfig> get applications -n argocd
kubectl --kubeconfig <kubeconfig> get pods -AThe current CLI no longer has cub unit apply or cub unit livestate, which this page named before. A live run on 2026-10-08 with cub v0.8.7 ran both cub release commands in a Space with no release Target, and the run log holds the output. cub release list --space <space> printed an empty list. cub release publish <space> was refused with "cannot release a Space without a ReleaseTargetID". A publish with a release Target was not run, and neither were the kubectl lines. The run found no command that reads one Unit's live state, so that step is not documented yet.
cub variant upload exits 0 when a Link fails on a quota. The same run saw link FAILED lines for a Space whose Units were all written. Read the whole upload output on a large component, and check the Link quota first.
For GitOps/OCI, check both the root application and the child resources:
kubectl --kubeconfig <kubeconfig> get applications -n argocd
kubectl --kubeconfig <kubeconfig> describe application <app> -n argocd
KUBECONFIG=<kubeconfig> cub-scout gitops status --jsonHow To Read The Result
Use a funnel:
- Rendered objects exist.
- Units uploaded to ConfigHub.
- OCI/GitOps source exists.
- GitOps controller syncs.
- Target facts and lifecycle prerequisites are present.
- Workloads converge.
- Controller aggregate health is explained.
If stages 1-6 pass but stage 7 remains unclear, the result is watch, not a render-parity failure. Consul currently demonstrates this: the root Argo Application can be Synced/Healthy, workloads can converge, semantic parity can pass, and a child resource such as the UI Ingress can still leave controller health in Progressing.
What To Capture
For large charts, a useful receipt or issue comment should include:
- chart, version, base, target, and delivery path;
- Unit count and main Kubernetes kinds;
- elapsed time for upload, apply, GitOps sync, and workload convergence when available;
- the exact command that was waiting;
- the first resource that stayed pending, blocked, or progressing;
- whether the residue is a parity defect, target prerequisite, controller health watch, or missing product progress signal.
Current Product Gap
The current CLI path does not always show enough progress for large operations. The desired product behavior is a progress stream or receipt fields that show which phase and Unit group are active. Until then, use the commands above to make the funnel visible.
Tracked in issue #714.