Skip to content

docs: k3d-gpu eas, EAT 2.0 through EAS, upstream re-read; ledger F3 pre-registration - #249

Merged
88plug merged 5 commits into
mainfrom
claude/eas-eas-docs
Oct 30, 2026
Merged

docs: k3d-gpu eas, EAT 2.0 through EAS, upstream re-read; ledger F3 pre-registration#249
88plug merged 5 commits into
mainfrom
claude/eas-eas-docs

Conversation

@88plug

@88plug 88plug commented Oct 29, 2026 •
edited
Loading

Copy link
Copy Markdown
Owner

This is the docs and ledger part of full EAS support. It documents k3d-gpu eas, refreshes the upstream re-read for EAT 2.0 through EAS, and pre-registers F3, the one scored run of the EAS path. Nothing here says EAS works on k3d-gpu: F3 is PENDING, and every page that mentions k3d-gpu eas says so.

Stacking and merge order

  • Based on eas: k3s/k3d patch overlay that drops each patch once upstream carries the fix #248 (claude/eas-eas-overlay), so the overlay section documents the real overlay.json and overlay.py, and the edit to integrations/eat/upstream/README.md line 11 builds on eas: k3s/k3d patch overlay that drops each patch once upstream carries the fix #248's version of that line instead of conflicting with it.
  • It also depends on the eas CLI part and the eat-up.sh move to release-1.1.0 (the eat-110 part). Neither PR exists yet, so the pages follow the spec's interfaces for them: k3d-gpu eas up|status|check|down, integrations/eas/pins.json, integrations/eas/known-issues.json, the refusals, and eat-up.sh on release-1.1.0 with the guardrail off and vLLM CPU v0.28.0 by digest. Merge this after both, and rebase it if their interfaces differ.
  • W13 (claude/fresh-*) and W14 (claude/agentstack-*): no PRs or origin branches (re-checked 2026-10-29 21:10 UTC), but both now have local worktrees with uncommitted work. W14's claude/agentstack-eas-agent-toolkit holds an untracked integrations/eas/ (eas-up.sh, eas-facts.py, bastion.Dockerfile, constraints.txt, images.yaml and patches/0006-envoy-control-plane-affinity-rc1.patch, on EAS v1.2.0-rc.1), which overlaps eas: k3s/k3d patch overlay that drops each patch once upstream carries the fix #248's integrations/eas/ and its release-1.2 form of 0006; claude/agentstack-eat-release-1-1-0 moves eat-up.sh to release-1.1.0, as claude/eas-eat-110 does; claude/agentstack-sandbox-ownership edits scripts/k3d-gpu. W13's claude/fresh-known-issues and claude/fresh-pin-classes add pins/known-issues.toml and pins/classes. This series was pushed first; the two need reconciling before either lands.

What changes

  • New page docs/intel/eas.md, in the nav under Integrations. It covers what "full EAS" means (platform, inference and agent-toolkit on the Xeon CPU path; ERAG refused), the commands, the automatic choices as fact, choice and permalink, the refusals, the overlay decisions per profile, the pins and how to move them, EAT's minimums against what eas up does on a smaller host, the known issues, state and secrets, and the limits.
  • docs/intel/upstream-eat.md: a second 2026-10-29 re-read and a new SHA table (EAS 97f6157, enterprise-inference 3e8a244, EAT release-2.0.0 036b662 with the same tree as fb59459, EAS v1.2.0-rc.1 5c27fb3, plus the Gate 1 and Gate 2 bases). It records that rc.1 is Intel's vehicle for EAT 2.0, that 0005 and 0006 fail there and the overlay's second 0006 variant covers it, the feat: opt-in telemetry manifests (RAPL, P/E-core, Intel GPU, DCGM) #50, Helm-adoptable NRI balloons, EAT hybrid profile and reservation patch #52 and feat: k3d-gpu audit and images.lock (console slice S5) #61 conflicts, the source findings (agent-sandbox, NFD, require_amx, pod CIDR, Kata, NRI owner, memory, version skew, H26 rdt-isolate: auto noisy-neighbour isolation mode in doctor + pre-registered probe #71 teardown), the ERAG finding, and that Gate 2 covered platform and inference only, so EAT 2.0 on k3d is unverified until F3.
  • docs/platforms.md (EAT section and PR table rows build: devcontainer and make check running every repo validator #19 and ci: run the host-setup, KubeRay and simulated-hardware suites #21), docs/intel.md (the EAT intro and the defaults table), README.md (the EAT section) and integrations/eat/upstream/README.md line 11 now name the two paths: eat-up.sh for EAT 1.x and k3d-gpu eas up --agent-toolkit for EAT 2.0. The anchor #eat-pull-requests-checked-2026-10-28 is kept, because docs/intel.md links to it.
  • EXPERIMENTS.md: the F3 row (PENDING) and the section "F3 pre-registration (i9-13900T, 2026-10-29)", in their own commit ahead of the docs. F3 runs from the first main commit that holds this section, k3d-gpu eas and the eat-up.sh move, after the CLI part's wiring smoke. It grades the printed choices and overlay decisions against a fixed table, the install's PLAY RECAPs, a Ready wait, eas check through the EAS gateway, a secret scan over logs and sampled argv, and eas down. Prior P(SUPPORTED) = 0.35.

A finding for the eat-110 part

On release-1.1.0, deploy-agentic-stack.sh sets DEPLOY_GUARDRAILS="${DEPLOY_GUARDRAILS:-on}" at top level (line 195), and reads deploy_guardrails= from agentic-config.cfg only inside main() (line 1138), which a sourced brownfield run skips. Setting the key in agentic-config.cfg alone therefore leaves the guardrail on; brownfield.sh also has to export DEPLOY_GUARDRAILS=off. The docs here say only that the guardrail stays off, not how.

Review fixes (2026-10-29)

An independent read against EAS 97f6157, enterprise-inference 3e8a244, EAT 036b662, ERAG 319eb46 and Envoy Gateway v1.7.1 changed these, in two commits on top:

  • ledger(F3): a precedence paragraph, written before any F3 step. Three INCONCLUSIVE conditions (step 3 stopped while pods still pull, a registry or Hugging Face error, no model fits) always also met a REFUTED one; such a consequence now grades INCONCLUSIVE and every other REFUTED condition grades REFUTED. The prediction and the conditions are unchanged.
  • LiteLLM and Langfuse come with auth_type: litellm_vkey, which the agent-toolkit layer sets; a plain inference install uses Keycloak JWT (EI components.yaml#L42-L53, config.yaml#L44; Gate 2 probe 5). The layer table, eas check, the curl line and the secrets note say so. The CLI part's eas check and --resolve litellm.<domain> line only apply with --agent-toolkit.
  • eg-gateway is the Gateway, not a Service: Envoy Gateway names the proxy Service envoy-<ns>-<name>-<hash>. Step 5 reads the Gateway's status.addresses.
  • ERAG's default flavour chatqna is a Xeon (CPU) deployment, so the missing EI vllm-xpu runtime only blocks its experimental GPU flavour. The docs say ERAG is not wired in yet and is the follow-up on the CPU path, rather than refused for the GPU reason.
  • -e llm_services_deploy_models=false does not replace --skip-models under --agent-toolkit: the chat model and Qwen3Guard deploy whatever that key says. The docs use llm_services_autodeploy_models: [].
  • For the CLI part: es_auto_installer.sh runs ensure_sudo before every install and adds --ask-become-pass without passwordless sudo (#L866-L875, #L1179, #L1423), so a bastion run as the host uid needs passwordless sudo or root.

How the facts were checked (2026-10-29, read only)

Tests

Check Result
tests/docs_test.sh (pinned docs image) 63 passed, 0 failed
mkdocs build --strict (same image) built, no warnings; every eas.md anchor resolves
tests/platforms_doc_test.sh 195 passed, 0 failed
tests/claims_check.sh / tests/claims_check_test.sh 27 files clean / 81 passed
tests/ledger_drift_check.py / its test 42 files agree with 81 ledger rows / 34 tests OK
tests/pe_premise_check.sh / its test ok / 16 passed
console/ledger-rules.json against EXPERIMENTS.md matches
tests/bench_vs_test.py, tests/gate_merge_test.sh 27 OK, 31 passed
tests/eas_test.sh (from #248, on this branch) 86 passed, 0 failed

No cluster was run, and nothing was posted to any intel repository.

88plug added 3 commits October 29, 2026 13:52
@88plug
eas: k3s/k3d patch overlay that drops each patch once upstream carrie…
14eef6d 
…s the fix

integrations/eas/overlay.py decides, per row of integrations/eas/overlay.json
and at one EAS commit, whether a k3s/k3d patch is skipped (not needed on this
cluster), dropped because upstream merged it (git apply -R --check), dropped
because upstream fixed it another way (a probe matches and the knob the
generator writes is still there), applied (first variant whose git apply
--check passes), or a STOP that names the upstream change that moved the hunk
and says to regenerate. Every decision prints as `fact -> choice [source]`,
with --explain giving permalinks. Decisions read the commit through a scratch
index, so they do not change once the overlay is applied; --apply writes the
working tree only when nothing STOPs, and a re-run is a no-op.

Patches are looked up in integrations/eas/patches, then in the upstream
drafts, so the drafts stay the only copy. The one new patch is the
release-1.2 form of 0006, where the EnvoyProxy task is still in
roles/envoy_gateway/tasks/install.yaml.

tests/eas_test.sh (section overlay) runs it on synthetic git repos built from
byte-identical copies of the EAS files the patches touch, at main 97f6157
and release-1.2 5c27fb3. apply-check.sh gains --overlay, which checks the
recorded decisions on a real clone and prints them for branch tips and open
EAS PRs #50, #52 and #61.
@88plug
ledger(F3): pre-register the k3d-gpu eas functional check
22daf86 
F3 is one scored run of `k3d-gpu eas up --agent-toolkit` on a fresh, default
k3d-gpu cluster on the i9-13900T at the "main" profile pins (EAS 97f6157,
enterprise-inference 3e8a244, EAT release-2.0.0 036b662). It grades the printed
auto-choices and overlay decisions against a fixed table, the install's
PLAY RECAPs, a Ready wait, `eas check` through the EAS gateway, a secret scan
over logs and sampled argv, and `eas down`. The row is PENDING; the run waits
for the eas CLI and the eat-up.sh release-1.1.0 move to reach main.
@88plug
docs: k3d-gpu eas, EAT 2.0 through EAS, upstream re-read
318d18e 
New page docs/intel/eas.md (in the nav under Integrations) documents
`k3d-gpu eas`: what "full EAS" covers, the commands, every automatic choice
with the fact it reads and a permalink to the upstream line behind it, the
refusals, the patch overlay with its expected decisions for the main and
v1.2.0-rc.1 profiles, the pins and how to move them, EAT's hardware and
inotify minimums against what `eas up` does on a smaller host, the known
issues, and the limits (Xeon CPU path only; Arc and Gaudi stay with
`k3d-gpu agent up`; ERAG refused until an enterprise-inference vLLM-XPU
runtime exists).

docs/intel/upstream-eat.md gets a second 2026-10-29 re-read and a new SHA
table: EAS main 97f6157 still passes every patch and the series; on
v1.2.0-rc.1 (5c27fb3) 0005 and 0006 fail, which the overlay's second 0006
variant covers; open EAS PRs #50 and #52 break 0006 and #61 breaks 0002,
0004 and 0005. It lists the source findings for a k3d BYO install of EAT
2.0 and says Gate 2 covered platform and inference only, so EAT 2.0 on k3d
stays unverified until F3 runs.

docs/platforms.md, docs/intel.md, README.md and the upstream pack README
now name the two paths: eat-up.sh on EAT release-1.1.0 for EAT 1.x, and
`k3d-gpu eas up --agent-toolkit` for EAT 2.0, with F3 PENDING.
@88plug 88plug mentioned this pull request Oct 29, 2026
Merged
@88plug

88plug commented Oct 29, 2026

Copy link
Copy Markdown
Owner Author

The config generator for this page is in #251, which is stacked on #248 like this PR. Five points in docs/intel/eas.md differ from what #251 builds:

  • The KV cache from fit is capped at the catalog value. EI renders the catalog's memory as both the pod's request and its limit, while fit sizes against the host, so fit can lower VLLM_CPU_KVCACHE_SPACE but not raise it.
  • pins.json rows also carry a profile field: {profile, name, repo, ref, sha, date, source}.
  • There are two more refusals: an unknown CNI bin_dirs layout, and an agent-sandbox version that is neither k3d-gpu's nor EAT's v0.5.0.
  • best-effort is also chosen when the node has no NRI socket.
  • The agent_sandbox router and runtime images are not pinned by digest in eas: EAS and EAT config from cluster facts, the pins file, fixture tests #251. The design leaves those digests to the bastion part.

88plug added 2 commits October 29, 2026 14:17
@88plug
ledger(F3): state which verdict wins when grading conditions overlap
bdf3533 
Three of F3's INCONCLUSIVE conditions always also meet a REFUTED one: step 3
stopped at 100 min while pods are still pulling exits non-zero, a registry or
Hugging Face error fails the step it happens in, and a run where no model fits
cannot pass `eas check`. Without a rule the grader could pick either verdict
after the fact. The added precedence paragraph, written before any F3 step,
grades such a consequence INCONCLUSIVE and every other REFUTED condition,
a choice or overlay decision that differs from the table included, REFUTED.
The prediction and every condition are unchanged.
@88plug
docs(eas): match the layer contents, gateway, ERAG and skip-models no…
360f8e8 
…tes to source

Read against EAS 97f6157, enterprise-inference 3e8a244, EAT 036b662, ERAG
319eb46 and Envoy Gateway v1.7.1:

- LiteLLM and Langfuse are not part of a plain inference install. EI enables
  them only with auth_type litellm_vkey (components.yaml L42-L53) and defaults
  to jwt (config.yaml L44), which is how Gate 2 probe 5 reached its model;
  EAT's layer config sets litellm_vkey (config.yaml L24). The layer table,
  `eas check`, the curl line and the secrets note now say LiteLLM comes with
  --agent-toolkit.
- No Service is named eg-gateway. eg-gateway is the Gateway; EAS sets no
  Service name, so Envoy Gateway names the proxy Service envoy-<ns>-<name>-<hash>
  (resource_provider.go L299-L304). Step 5 reads the Gateway's status.addresses.
- ERAG's default flavour, chatqna, is a Xeon (CPU) deployment
  (deployment/README.md L3), so the missing EI vllm-xpu runtime only blocks its
  experimental Intel GPU flavour. The docs now say ERAG is not wired in yet and
  is the follow-up on the same CPU path, instead of refusing it for the GPU
  reason; README no longer says the three layers are all EAS ships on Xeon.
- The --skip-models row: EI's seeded config already has
  llm_services_deploy_models false, and with --agent-toolkit the chat model and
  the Qwen3Guard guard deploy whatever that key says (llm_services
  install.yaml L143-L161). The row and the `--` example now use
  llm_services_autodeploy_models [] and say the guard model stays.
- The installer runs ensure_sudo before every install and adds
  --ask-become-pass without passwordless sudo (es_auto_installer.sh L866-L875,
  L1179, L1423); the Limits note names it for the CLI part's bastion.
- Smaller fixes: #61's 0005 is skipped because it is docs, not because of the
  node count; the pod CIDR fallback only matters once LiteLLM admits the pod
  network (OpenShell); k3d-gpu owns the balloons policy on a hybrid or
  multi-NUMA host.
This was referenced Oct 29, 2026
Open
Merged
Open
@88plug
88plug changed the base branch from claude/eas-eas-overlay to main October 30, 2026 00:17
@88plug 88plug mentioned this pull request Oct 30, 2026
Merged
@88plug
88plug merged commit 5abac85 into main Oct 30, 2026
1 check passed
88plug added a commit that referenced this pull request Oct 30, 2026
@88plug
batch: land #248, #251, #250, #249, #247, #243 (#262)
6659ace 
Lands #248, #251, #250, #249, #247 and #243 in one merge.
This was referenced Oct 30, 2026
Open
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@88plug