Uh oh!
There was an error while loading. Please reload this page.
fix(installer): make the training size configurable at install (TRACEBLOC_TRAINING_RESOURCES) - #308
Merged
Merged
Conversation
The generated values hardcoded RESOURCE_LIMITS/REQUESTS to cpu=2,memory=8Gi with no way to override — the 'default configuration' was frozen. One env knob now sets both (requests == limits, Guaranteed QoS, matching client-runtime's lockstep default): TRACEBLOC_TRAINING_RESOURCES="cpu=4,memory=16Gi" bash <(curl … i.sh) Groundwork for the `tracebloc resources` command (design approved by Lukas 2026-07-06): that command becomes the friendly layer over the same chart values; this is the install-time escape hatch. +2 bats tests (override lands in generated values; default unchanged). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Closed
4 tasks
…rces-env-override # Conflicts: # scripts/manifest.sha256
saadqbal
approved these changes
Jul 7, 2026
Uh oh!
There was an error while loading. Please reload this page.
This was referenced Jul 8, 2026
LukasWodka added a commit
that referenced
this pull request
Aug 11, 2026
…ackend#1752) Org rule: a statement my change falsifies travels with the change. Four claims in docs/SECURITY.md were wrong the moment S2 shipped and the flag started resolving per environment: * `tb_meta` / `tb_ingest` were listed as "not yet consumed" --- S2 shipped (client-runtime#305/#308, client#664); they ARE consumed where the flag is on * `edgeuser` was listed as the default identity for jobs-manager, requests-proxy and ingestion pods "today" --- true only on prod now * "gated on serviceDbAccounts (default off) ... purely additive ... a default install authenticates exactly as it did before" --- wrong on both counts * the S1/S2 rollout steps still read as pending AND THE DOCUMENT DID NOT MENTION THE HAZARD AT ALL, which is the part that actually cost us a day. The ingestor REQUIRES DB_USER/DB_PASSWORD from 0.8.0 (data-ingestors#468) and jobs-manager injects them only when the flag is on, so a fleet on an ingestor >= 0.8.0 with the flag OFF fails every ingestion Job at Config(). §4.1.1 now states the ordering as an explicit constraint --- turn the flag on for a fleet BEFORE its ingestor moves to 0.8.x, never after --- names the prod-specific form of it (before prodDigest moves past 0.8.2, client#490), and points at the CI check that enforces it (backend#1754). A security doc that describes a retired fallback as present is worse than one that says nothing: it is the document someone reads before flipping a prod fleet. 384 chart tests, style guard and fact-check clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
LukasWodka added a commit
that referenced
this pull request
Aug 12, 2026
… staging ingestion (backend#1752) (#676) * fix(chart): resolve serviceDbAccounts per environment — unbreak dev + staging ingestion (backend#1752) dev and staging ingestion are broken right now. Verified by running the published images, not inferred: ghcr.io/tracebloc/ingestor:dev -> 0.8.5, DB_USER raises ValueError ghcr.io/tracebloc/ingestor:stg -> 0.8.5, DB_USER raises ValueError prodDigest sha256:9098b3c9… -> 0.7.7, DB_USER = 'edgeuser', works data-ingestors#468 removed the ingestor's edgeuser fallback on the stated precondition that this flag was "on fleet-wide". It was on NOWHERE. dev and staging edges float on the :dev/:stg channels and took the change the same day, so every ingestion Job fails at Config() before reading a byte. Prod escaped only because its ingestor is digest-pinned to the 0.7 line --- a caution engineered for D16, not for this, and one client#490 is about to spend. #1151 records the rollout as "flip per environment, dev first". There was no MECHANISM for that: one global boolean meant "per environment" was hand-editing every edge and remembering which fleet was where. The fleet's posture could not be read in one place and nothing tested it. So the flag now resolves like `channelTags` already does --- an explicit `serviceDbAccounts` override wins, otherwise `serviceDbAccountsByEnv` keyed on the RESOLVED CLIENT_ENV: dev: true both are already running the ingestor that requires the stg: true per-Job credentials, so this is what makes them work again prod: false explicitly. Prod runs the 0.7-line ingestor, which still has the fallback; flipping prod is a separate windowed decision (#1528 S0 drill) and must happen BEFORE prod's ingestor is repinned past 0.8.2. Resolved through `tracebloc.clientEnv`, so a documented alias like `staging` maps to `stg` rather than silently missing its entry --- that is backend#1723, one env-name spelling away, and it has its own test. The Secret and the jobs-manager env are gated on the same resolver, so a flip stays atomic: jobs-manager fail-fasts when the flag is on and the Secret is unwired, and a half-flip would crash-loop it. 384 chart tests (was 375). Mutation-checked: reverting the templates turns the dev/stg cases red, and swapping the resolver for a raw CLIENT_ENV lookup turns the `staging` alias case red on its own. One note for review, PRE-EXISTING and not from this change: with the flag on, secrets.yaml renders TWO Secrets both named `<release>-secrets`. Identical on develop with `serviceDbAccounts=true`, so out of scope here, but worth a look. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(security): §4.1.1 + §8.10 said things this change makes false (backend#1752) Org rule: a statement my change falsifies travels with the change. Four claims in docs/SECURITY.md were wrong the moment S2 shipped and the flag started resolving per environment: * `tb_meta` / `tb_ingest` were listed as "not yet consumed" --- S2 shipped (client-runtime#305/#308, client#664); they ARE consumed where the flag is on * `edgeuser` was listed as the default identity for jobs-manager, requests-proxy and ingestion pods "today" --- true only on prod now * "gated on serviceDbAccounts (default off) ... purely additive ... a default install authenticates exactly as it did before" --- wrong on both counts * the S1/S2 rollout steps still read as pending AND THE DOCUMENT DID NOT MENTION THE HAZARD AT ALL, which is the part that actually cost us a day. The ingestor REQUIRES DB_USER/DB_PASSWORD from 0.8.0 (data-ingestors#468) and jobs-manager injects them only when the flag is on, so a fleet on an ingestor >= 0.8.0 with the flag OFF fails every ingestion Job at Config(). §4.1.1 now states the ordering as an explicit constraint --- turn the flag on for a fleet BEFORE its ingestor moves to 0.8.x, never after --- names the prod-specific form of it (before prodDigest moves past 0.8.2, client#490), and points at the CI check that enforces it (backend#1754). A security doc that describes a retired fallback as present is worse than one that says nothing: it is the document someone reads before flipping a prod fleet. 384 chart tests, style guard and fact-check clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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.
Summary
The generated values hardcoded
RESOURCE_LIMITS/REQUESTS: cpu=2,memory=8Gi— the install-time default was frozen with no override. One env knob now sets both (requests == limits, Guaranteed QoS, matching client-runtime's deliberate lockstep):Documented in the installer header + a YAML comment in the generated values. Groundwork for the
tracebloc resourcescommand (design approved; ticket in tracebloc/cli) — that becomes the friendly runtime layer over the same chart values.Testing
+2 bats tests (override lands in generated values / default unchanged); full install-client-helm suite 48/48 locally (Linux CI authoritative). manifest.sha256 regenerated.
🤖 Generated with Claude Code