Repository navigation
batch: land #264, #256 - #272
Merged
Merged
Conversation
…ure queue
Every upstream bug, behaviour change and advisory k3d-gpu depends on is now an
entry in pins/known-issues.toml with its affected range and the first release
that fixes it. hack/known-issues check (offline, in CI as the known-issues job)
fails when an "ours" pin stays inside a fixed issue's range ("bump <file> to >=
<fixed_in>"), when a workaround marker outlives its fix without a retained
reason, or when markers and entries disagree. eat-stock sites and ledger
references in range are reported, never failed. hack/known-issues poll reads
GitHub (read-only) and finds the first stable release containing each fix: the
fix commit is compared against release tags walked in version order, a
{repo, path, contains} fix reads the file at each tag, and advisories come from
the GitHub advisory database.
hack/pinver.py is the shared version library: semver, zerover, k8s, llama.cpp
builds and releases, calver, PEP 440, docker suffix tags, apt and Hugging Face
revisions, with ranges, update types and each scheme's breaking rule.
hack/ledger-freshness lists SUPPORTED ledger rows whose recorded component
versions are a minor or major behind today's pins, or inside a known issue's
range, ordered by ledger-rules rows, then rows docs claims cite (new
tests/claims_check.sh --cited), then the rest. It writes nothing.
Seeded: vllm-45844 (fixed in 0.25.0), vllm-50801, vllm-pr-51493,
linux-npu-driver-56, kserve-4592, eat-9, the LiteLLM 1.83.14 advisories and
the vLLM 0.32 num_speculative_tokens ordering bug, with markers at the
workaround sites in console/, scripts/k3d-gpu, docs and examples/kserve.
… real-repo tests The ledger re-measure test fixture names cryptoandcoffee/k3d-gpu:0.1.70 as a recorded node image, which the image pin gate (images-lock pins) flagged; it is now allowed in images.unpinned as a test input that is never pulled. The vllm-pr-51493 workaround in console/model_opt.py is one clause of a note string inside an if block, so it carries a single known-issue marker instead of a begin/end pair whose deletion would leave the block empty. The real-repo tests no longer name today's pins: the vLLM CPU pin is moved to v0.24.0 by pattern, and H34's recorded OVMS version is checked by shape, so a version bump that substitutes strings in tests/ does not turn them red.
…GPU plugin, Kata and rack-scale mode (failing) Section 3d of tests/eat_test.sh: on release-1.1.0, eat-up.sh is to stop before it touches the cluster when the config's deploy_nri_balloon_policy is anything but off or no (absent included: brownfield.sh model mode's prompt_for_input turns it on for compute_platform c), when compute_platform is x or xpu, when deploy_kata_containers is on or yes, and when rack_scale_mode is on or yes. The keys are read as read_config_file reads them: trimmed, unquoted, last assignment wins. The xpu refusal must name vLLM on an Intel GPU through k3d-gpu agent up.
…d-gpu cluster eat-up.sh now stops before it touches the cluster, reading each key as release-1.1.0's read_config_file does, when the config: - sets deploy_nri_balloon_policy to anything but off or no. fresh-install.sh:247 deploys EAT's NRI balloons policy on yes, beside k3d-gpu's, and brownfield.sh model mode's prompt_for_input turns an absent key on for compute_platform c (parse-user-prompts.sh:55-66). - sets compute_platform to x or xpu. fresh-install.sh:219 then applies intel-device-plugins' gpu_plugin from its main branch, unpinned (deploy-intel-gpu-plugin.yml:12-14), beside the plugin k3d-gpu bakes. The message points at K3D_GPU_AGENT_BACKEND=vllm k3d-gpu agent up. - sets deploy_kata_containers on: Kata needs /dev/kvm, which a k3d node lacks. - sets rack_scale_mode on: it builds its own cluster from rack-profile.yaml (netplan, BGP, the NVIDIA GPU operator; fresh-install.sh:195-210). The shipped agentic-config.cfg already writes each of these off, so the default path is unchanged. Line numbers are at 0c726f5. integrations/eat/README.md (blockers 10 and 12) and the XPU notes in docs/platforms.md say so.
… EAT tag scheme The advisory poll read only the advisories that affect the lowest site version. A patched version could itself sit inside an advisory that does not affect that version, and a backport below the site version or a prerelease could be chosen as the fix. It now takes the first stable patched version above the site version, reads that candidate's own advisories, and moves on until a candidate has none. That changes the LiteLLM entry. GHSA-7hp6-4w63-5g45 (high, published 2026-10-27) affects 1.91.0 through 1.100.3, so the recorded fix 1.95.1 was itself vulnerable. The first release outside every advisory is 1.100.4; the entry now lists GHSA-7hp6 and the wider affected range. A live poll reads fixed_in 1.100.4 with no mismatch and no new advisories. EAT's releases are one stream of release-X.Y.Z and release-X.Y.Z-hotfix tags. Under docker-suffix a hotfix tag and a plain release are different flavours, so the eat-9 poll saw only hotfix releases and could never find a fix shipped in release-1.1.0 or later, and latest() could not move off a hotfix. pinver gains an eat scheme that orders the two forms in one stream, and eat-9 uses it. The re-measure queue gave two rows of one family the same suggested follow-up id; each suggestion is now taken before the next is chosen.
…eploys EAT's policy fresh_installation calls prompt_for_input (fresh-install.sh:39) on the stack path, so with deploy_nri_balloon_policy absent and compute_platform c the key turns on there and fresh-install.sh:247 deploys EAT's balloons policy beside k3d-gpu's. The refusal, its comment and the docs tied the absent key to model mode only. In model mode no policy is deployed: brownfield.sh's prompt_for_input call sets balloon_policy_cpu, and deploy-inference-models.yml then sets vLLM's cpu_balloon_annotation to vllm-balloon-tp<N>, a balloon type k3d-gpu's policy does not define, over the performance balloon vllm-values.yaml asks for. The guard itself is unchanged: any value but off or no still stops eat-up.sh. tests/eat_test.sh checks that the absent-key refusal says the policy is deployed when the key is on or absent.
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Lands two reviewed PRs in one merge, with one CI run for both. Each is merged with --no-ff, so its commits keep their own history.
No ledger rows change, so docs/intel/technical-report.md and console/ledger-rules.json need no update. Local checks on the batch head: every suite in .github/workflows/ci.yml that runs without extra tooling (including the new hack/known-issues check, known_issues_test, ledger_freshness_test and pinver_test from #256), render_test with the pinned helm, the simulated hardware matrix, the agent examples, tests/claims_check.sh and tests/ledger_drift_check.py.