Uh oh!
There was an error while loading. Please reload this page.
Conversation
…5) (#293) Third R8 install regression found running curl|bash end to end: the #279 reorder mints the credential (Step 3) and deploys the client pod (Step 4) BEFORE Step 5's verify_credentials. A freshly minted client is "set to enroll" — it goes active only once the deployed pod connects — so verify_credentials (api-token-auth) returns 400/invalid and hard-fails a perfectly good install: "TRACEBLOC_CLIENT_ID / TRACEBLOC_CLIENT_PASSWORD was rejected by tracebloc". A minted credential is valid by construction (client create just made it), so pre-verifying it adds no correctness value and only races enrollment. Trust the mint; the deployed pod enrolls the client. - provision.sh: export TRACEBLOC_CLIENT_MINTED=1 on the mint path (cleared up front, not set on adopt / dual-mode). - install_client_helm Step 5: when minted, skip verify_credentials and show a non-fatal "Provisioned client N — it will connect shortly" instead of erroring. User-entered / dual-mode creds still verify (those can be wrong). - manifest.sha256 regenerated (provision.sh + install-client-helm.sh are pinned); chart 1.8.2 -> 1.8.3. Tests: provision.bats asserts the mint sets MINTED (adopt doesn't); install-client- helm.bats adds a test that a minted credential skips verify and succeeds even when verify would return invalid. shellcheck clean; gen-manifest --check passes. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
…vert #293 → v1.8.4) (#295) #293 skipped verify_credentials for freshly-minted credentials on the premise that a minted client is "set to enroll" and only goes active once the pod connects, so the api-token-auth pre-verify would 400 on a valid credential. That premise was wrong. The real reason verify 400'd was a CLI bug (tracebloc/cli#125): `client create` wrote the numeric dashboard id — not the UUID username — as TRACEBLOC_CLIENT_ID, which is the auth username. The credential was genuinely invalid; verify_credentials was a correct canary that #293 masked, letting the install "succeed" while the pod crash-looped on "Unable to log in with provided credentials". With cli#125 fixed (v0.5.1), a minted credential is valid and verify passes. Restore the canary so a bad credential fails loudly at install time (Step 5) instead of silently at pod runtime: - install-client-helm.sh: drop the TRACEBLOC_CLIENT_MINTED skip branch; always verify_credentials in Step 5 (mint, adopt, and dual-mode alike). - provision.sh: drop the TRACEBLOC_CLIENT_MINTED marker (now unused). - tests + manifest.sha256: reverted to the pre-#293 state. - Chart: 1.8.3 → 1.8.4 (forward; not a version rollback). DEPENDS ON tracebloc/cli#125 (v0.5.1) being the latest CLI release — the installer fetches the CLI fresh, so the canary only passes once v0.5.1 mints the correct UUID username. Do not release this chart before v0.5.1 is out. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
…d client in place (RFC-0001 §7.2 / #838) (#298) * fix(installer): honor TRACEBLOC_CLIENT_ADOPTED — reconcile a connected client in place (RFC-0001 §7.2 / #838) Re-running the installer on an already-connected client did not behave per RFC-0001 §7.2. provision_client (Step 3) correctly adopts the existing client (get-or-create keyed on the cluster) and writes TRACEBLOC_CLIENT_ADOPTED=1 + the UUID + namespace to the credential file — but install-client-helm.sh had NO adopt handling. Its non-interactive path is gated on ID *and* PASSWORD both being set; adopt issues no password (the existing one stands, write-only on the backend), so Step 5 fell through to the manual "Client ID:" prompt, defaulting to the stale clientId in the previous values.yaml — a numeric dashboard id on any cluster first installed during the cli#125 window — which verify_credentials then rejected. Teach Step 5 an adopt branch: on TRACEBLOC_CLIENT_ADOPTED=1, find the live client release and `helm upgrade` it in place, reusing its stored credential (no prompt, no verify, no duplicate) and healing the stored clientId to the adopted UUID so a cli#125-era install self-corrects. Prefer --reset-then-reuse-values (Helm >= 3.14), fall back to --reuse-values. Falls through to the normal connect flow only when no live release is found. The "previous settings?" prompt is skipped on adopt. Extracted _resolve_chart_ref (shared by the fresh-install and adopt paths). bats: 3 new adopt tests (reconcile-in-place + heal, older-Helm fallback, no-release fallback); full suite green (47). No Chart.yaml bump here — ships with #295 as v1.8.4 (avoids a version conflict). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(installer): adopt-reconcile must not depend on TRACEBLOC_CLIENT_ID (Bugbot) Bugbot (High): _reconcile_adopted_client read the adopted UUID from TRACEBLOC_CLIENT_ID for --set clientId, but provision_client CLEARS TRACEBLOC_CLIENT_ID on a real adopt (keeping only TB_NAMESPACE + TRACEBLOC_CLIENT_ADOPTED=1 — "let install_client_helm reconcile the existing release from the local values.yaml"). So reconcile always bailed on the empty id and fell through to the interactive prompt — exactly what this PR set out to fix. The bats tests masked it by exporting TRACEBLOC_CLIENT_ID directly. Reconcile the discovered live release in place with --reset-then-reuse-values (fallback --reuse-values), reusing its stored credential — no dependency on TRACEBLOC_CLIENT_ID, no --set clientId heal (which fought provision's design and couldn't work anyway). Tests now export ONLY TRACEBLOC_CLIENT_ADOPTED=1, matching what provision_client actually leaves in the env. Manifest regenerated. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(installer): heal clientId on adopt via provision handoff (Bugbot ×2) Resolves both Bugbot findings on the adopt path, which were in tension: • High — reconcile read the UUID from TRACEBLOC_CLIENT_ID for --set clientId, but provision_client cleared it on adopt → reconcile bailed on the empty id and fell through to the interactive prompt. • Medium — the interim fix reconciled with --reuse-values only, so a cli#125-era numeric clientId was preserved and the workload still couldn't auth. provision_client now KEEPS + exports the adopted client id (its UUID username) on the adopt path (dropping only the absent password), so install_client_helm can: • heal the stored clientId to the UUID via `--set clientId=<uuid>` when present (reused values keep the correct stored password) — fixes cli#125-era installs; • reconcile WITHOUT a heal (no bail to a prompt) when no id was handed over (rebuilt host / R7 orphan) — the existing credential stands. Optional --set built as an args array (bash-3.2 safe). Tests: heal-with-UUID + no-id-reconcile-fallback for Step 5; provision adopt test asserts the id is kept. provision.bats 12/12, install-client-helm.bats green; manifest regenerated. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
shujaatTracebloc
approved these changes
Jul 2, 2026
Uh oh!
There was an error while loading. Please reload this page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Promotes develop → main to cut v1.8.4 — the client-side half of the RFC-0001 credential-handoff fix (companion to cli v0.5.1 [shipped] + backend #941 [deployed to dev]).
What ships
verify_credentialscanary (reverts fix(installer): skip Step-5 pre-verify for freshly-minted credentials (→ v1.8.3) #293's skip-for-minted). fix(installer): skip Step-5 pre-verify for freshly-minted credentials (→ v1.8.3) #293 skipped verify on a wrong premise; the real cause was cli#125 (numeric id vs UUID username), now fixed in v0.5.1, so the canary is correct again.TRACEBLOC_CLIENT_ADOPTED: a re-run on an already-connected client reconciles the live release in place (RFC-0001 §7.2) instead of dropping to a manual prompt, and heals a cli#125-era numericclientIdto the UUID.(The delta includes #293's commit, but #295 reverts it — the net main state is canary-restored + adopt-reconcile.)
Fleet-safety
Chart templates + values are identical to v1.8.2 (verified) — only
Chart.yamlversion + the installer scripts changed. So the fleet auto-upgrade 1.8.2 → 1.8.4 is a no-op for running pods, just a version-label bump.Gates
skip-fr-gate(standard client-release process).