# Live run of ConfigHub commands, 2026-10-08 **UNOFFICIAL/EXPERIMENTAL** This log records one serial session against a hosted ConfigHub organization. It confirms or corrects commands that the site and the user docs show. It also walks one gpu-operator component with a variant for each chart version and a diff between versions inside ConfigHub. This is a dated record of one run. It is not a Guide, and it is not a run for any Catalog entry. The inputs were locally rendered files, and no cluster, Worker or Target was involved. Every line that starts with `$` is a command that was run, and the text under it is the output it printed. ## Versions and setting - The client is cub v0.8.7 (commit 072585f2, built 2026-10-07). - The server is v0.8.8 (commit 1bbdb335, built 2026-10-07). - Fifteen cub plugins are installed and `cub plugin list` prints no versions. No plugin command was used in this run. - The organization is a hosted ConfigHub organization. It held 44 Spaces and 12 Components before the run, and none of them was changed. - No cluster, Worker or Target was created or used. Nothing was applied, published or pushed. - Every object created here had a name that starts with `cwlive-1008-`. - The account address is written ``, the user identifier is written ``, the organization name is written ``, the token expiry time is written ` Server URL https://hub.confighub.com Token Expires --with-unit /`, as text, unified text or `-o mutations`. - A diff of two whole variant Spaces in one command is not available. A loop over the Unit names with the command above covers it when the Unit names match. - A diff of one whole Space between two uploads is available with `cub variant diff Before:ChangeSet: ChangeSet:`, or with `cub variant diff -end` to compare an earlier upload with the head. - A diff between the end tags of two different uploads is misleading. An upload tags only the Units it writes, so a Unit the later upload left unchanged shows as "absent" and reads as a whole removal. ## Check 11. Clean up The clones were deleted before their base, and each delete named one Space. ``` $ cub space delete --recursive cwlive-1008-redis-dev Successfully deleted space cwlive-1008-redis-dev (bd602121-1ec7-40c8-bbcf-e78743725105) $ cub space delete --recursive cwlive-1008-pattern-qa-cwlive-1008-redis-base Successfully deleted space cwlive-1008-pattern-qa-cwlive-1008-redis-base (5c88b313-f303-4b72-940b-41d5866ac17e) $ cub space delete --recursive cwlive-1008-redis-base Successfully deleted space cwlive-1008-redis-base (ccf72467-aced-4c06-b505-437128bd569a) $ cub space delete --recursive cwlive-1008-gpu-operator-rolling Successfully deleted space cwlive-1008-gpu-operator-rolling (dde654c5-c1c0-4aae-94ac-5d8b6b0ee71a) $ cub space delete --recursive cwlive-1008-gpu-operator-v25-10-1-driver-580-126-20 Successfully deleted space cwlive-1008-gpu-operator-v25-10-1-driver-580-126-20 (ba955841-6d0d-40ce-901f-7e4dd31b4225) $ cub space delete --recursive cwlive-1008-gpu-operator-v25-10-1 Successfully deleted space cwlive-1008-gpu-operator-v25-10-1 (5d53eaf0-b46b-434f-a7ba-80475a349525) $ cub space delete --recursive cwlive-1008-gpu-operator-v26-3-2 Successfully deleted space cwlive-1008-gpu-operator-v26-3-2 (9cb9d2a7-ea6a-4e72-913e-533739ebffb5) $ cub space delete --recursive cwlive-1008-gpu-operator-v26-3-3 Successfully deleted space cwlive-1008-gpu-operator-v26-3-3 (823a77e4-8ac3-4ec3-ab74-7aa952845822) $ cub component delete cwlive-1008-redis Successfully deleted component cwlive-1008-redis (092a71d5-250e-474e-9b00-c124ddd302bd) $ cub component delete cwlive-1008-gpu-operator Successfully deleted component cwlive-1008-gpu-operator (30aba121-dbd4-4caf-80ed-7d36b8c8e59e) ``` A ninth Space, `cwlive-1008-redis2-base` in the Component `cwlive-1008-redis2`, was created afterwards for the three follow-up commands in checks 6 and 8. It was then deleted the same way. ``` $ cub space delete --recursive cwlive-1008-redis2-base Successfully deleted space cwlive-1008-redis2-base (d22424f8-be77-4b4a-b13b-1c25d93927ef) $ cub component delete cwlive-1008-redis2 Successfully deleted component cwlive-1008-redis2 (9f205984-1029-4d98-97bb-55a56ae5a870) ``` Final verification. ``` $ cub space list --include-hidden --where "Slug LIKE 'cwlive-1008-%'" --no-headers | wc -l 0 $ cub component list --where "Slug LIKE 'cwlive-1008-%'" --no-headers | wc -l 0 $ cub unit list --space '*' --include-hidden --where "Labels.UploadSource LIKE 'cwlive-1008-%'" --no-headers | wc -l 0 $ cub trigger list --space '*' --where "Slug LIKE 'cwlive-1008-%'" --no-headers | wc -l 0 $ cub attestation list --where "AttestationID = 'd8c12c1b-c057-4f86-a2ab-7987afb4cf75'" ATTESTATION-ID TYPE RESULT REVOKES USER-ID CREATED $ cub space list --no-headers -o jq='.[].Space.Slug' | wc -l 44 $ cub component list --no-headers | wc -l 12 ``` The sorted list of Space names after the run is identical to the list taken before it, and so is the list of Component names. Everything created in the session, all of it now deleted. - Nine Spaces. They were `cwlive-1008-redis-base`, `cwlive-1008-redis-dev`, `cwlive-1008-pattern-qa-cwlive-1008-redis-base`, `cwlive-1008-gpu-operator-v25-10-1`, `cwlive-1008-gpu-operator-v26-3-2`, `cwlive-1008-gpu-operator-v26-3-3`, `cwlive-1008-gpu-operator-v25-10-1-driver-580-126-20`, `cwlive-1008-gpu-operator-rolling` and `cwlive-1008-redis2-base`. - Three Components. They were `cwlive-1008-redis`, `cwlive-1008-gpu-operator` and `cwlive-1008-redis2`. - One Trigger, `cwlive-1008-complete`, in the redis base Space. - One Approval attestation in the redis dev Space. It went with the Space. - The Units, Links, Tags and ChangeSets inside those Spaces. ## What went wrong 1. The session used up the organization's Link quota. The first seven Spaces held 141 Links between them, and the upload of the driver variant then reported `link FAILED gpu-operator-rolebinding -> gpu-operator-serviceaccount: exceeded maximum quota for entity type Link`. The three uploads into the rolling Space created no Links at all. The quota was exhausted for a few minutes, from the driver variant upload until cleanup began, and any other work in the organization that created a Link in that window would have been refused. A walk of this size needs Link headroom checked first, or fewer Spaces alive at once. 2. `cub variant upload` exits 0 when Links fail on quota. The Units were written and only the `link FAILED` lines say that something is missing. The failure was first missed here because only the first and last lines of the output were being read. 3. `cub unit diff` help lists `Tag:` and `ChangeSet:` as revision references. The server refuses both and says a reference must be a revision number, `-N`, `HeadRevisionNum` or `LastReleasedRevisionNum`. `cub variant diff` does accept Tags and ChangeSets. 4. A bare `cub unit diff ` fails on a Unit that has never been released, because the default `--from` is `LastReleasedRevisionNum`. The message is `Failed: revision LastReleasedRevisionNum not found or is invalid`. In a Space with no release Target, every example that relies on that default or names `LastReleasedRevisionNum` fails this way. 5. `cub unit diff --space ` with no Unit name is refused with `Failed: accepts between 1 and 3 arg(s), received 0`. One user doc showed that form at the time of the run. 6. `cub variant approve ` without `--all` prints `Nothing to record in : no unit has the selected revision` when the real reason is that no Unit has a Target. It exits 0. 7. A subcommand that does not exist, such as `cub unit livestate` or `cub unit set-predicates`, prints the group help and exits 0. There is no "unknown command" error, so a script that calls a removed command does not fail. 8. `cub variant create` has no `--dry-run` flag. The default Space name could only be observed by creating the Space. 9. When the base Space has no trigger selection, the clone is given a `WhereTrigger` that points at the base Space. "The selection is copied" is therefore true only in the sense the help gives. A clone of a base that has its own Triggers ends up running the base's Triggers, with a `WhereTrigger` the base itself does not have. 10. On an unchanged repeat upload, the "broke selector link" lines name Units as `redis-headless-redis-service` and `redis-master-statefulset`. Those are not the Unit names. The first upload printed the real names, `redis-headless-service` and `redis-master`. 11. `cub variant diff` between the end tags of two different uploads shows every Unit the later upload left unchanged as "absent". The ChangeSet form, or an earlier tag against the head, gives the true diff. 12. With `--change-desc`, a promotion records that description on the new revision in the variant. The description of the upstream change is not carried, which differs from the default the help describes. 13. `cub unit set-protection` prints the Unit's whole mutation record, including the full resource body, on success. `--quiet` is advisable in a guide. 14. `cub function get --quiet --show values get-yq ''` printed nothing, while the same command with `--show output` and no `--quiet` printed the values. 15. Rendered Secrets are skipped by design. The redis file has 14 objects and the Space has 13 Units, so "every resource becomes its own Unit" needs the words "except Secrets". 16. The top-level help tells AI agents to set `CONFIGHUB_AGENT=1` for help output. This run did not set it, so the help quoted here is the help a person sees. 17. Two commands in this session were run in one shell call, each to completion before the next started (the plain dry run and the real promotion in check 5). Nothing ran in parallel or in the background.