docs(disk-gc): record the correct access method for kagentz and docker-vm #85

Closed
abiba-bot wants to merge 0 commits from fix-litellm-health-keylist-20260913 into master
Owner

Partial fix for disk-gc-probe-false-unreachable-20260913. The contract's scanner reported kagentz (CT 105) and docker-vm (CT 109) as unreachable on every run while both hosts are up.

What this adds

A note in the CT 100 probe-gap section: for kagentz use ssh root@kagentz (hostname), NOT pct exec 105 - pct exec 105 reports loop0 (59G) while ssh reports the real filesystem (99G); for docker-vm use ssh root@192.168.68.7, not pct exec.

Known to remain (do not treat this PR as closing the item)

  • The scanner BEHAVIOUR has not been changed - only documented. If the executor still picks the wrong access method, the defect persists.
  • The duplicated/mis-sourced figures reported in the same run are NOT addressed: two different hosts rendered identical values ("abiba CT 100: 34% (13G/40G)" and "syslog-api CT 116: 34% (13G/40G)"), which cannot both be right and disagrees with earlier runs.
    Reviewers should judge whether a documentation-only change is acceptable here or whether the scanner itself must be corrected.
Partial fix for `disk-gc-probe-false-unreachable-20260913`. The contract's scanner reported `kagentz (CT 105)` and `docker-vm (CT 109)` as unreachable on every run while both hosts are up. ## What this adds A note in the CT 100 probe-gap section: for kagentz use `ssh root@kagentz` (hostname), NOT `pct exec 105` - `pct exec 105` reports loop0 (59G) while ssh reports the real filesystem (99G); for docker-vm use `ssh root@192.168.68.7`, not `pct exec`. ## Known to remain (do not treat this PR as closing the item) - The scanner BEHAVIOUR has not been changed - only documented. If the executor still picks the wrong access method, the defect persists. - The duplicated/mis-sourced figures reported in the same run are NOT addressed: two different hosts rendered identical values ("abiba CT 100: 34% (13G/40G)" and "syslog-api CT 116: 34% (13G/40G)"), which cannot both be right and disagrees with earlier runs. Reviewers should judge whether a documentation-only change is acceptable here or whether the scanner itself must be corrected.
abiba-bot added 1 commit 2026-09-13 04:35:33 +00:00
fix: disk-gc-threat-response - correct access methods for kagentz and docker-vm
PR Pipeline — Authorize → Validate → Review → Merge / auth (pull_request) Successful in 4s
PR Pipeline — Authorize → Validate → Review → Merge / validate (pull_request) Successful in 8s
PR Pipeline — Authorize → Validate → Review → Merge / lint (pull_request) Successful in 12s
PR Pipeline — Authorize → Validate → Review → Merge / ai-review (pull_request) Successful in 5s
PR Pipeline — Authorize → Validate → Review → Merge / gate (pull_request) Successful in 0s
c81cf5b6f0
- kagentz (105): use ssh root@kagentz (hostname), NOT pct exec 105 (shows loop0 59G, not real 99G)
- docker-vm (109): use ssh root@192.168.68.7 (correct QEMU VM access)
- abiba (100): use ssh root@abiba (hostname)
- syslog-api (116): use pct-run 116 (correct)

Verified:
  kagentz: 99G 8.9G 86G 10% /
  docker-vm: 158G 17G 135G 11% /
  abiba: 59G 13G 44G 23% /
  syslog-api: 40G 13G 25G 34% /
Author
Owner

Closed unmerged: the pre-delivery review returned FAIL on the correct ground - this is a documentation-only change in disk-gc-threat-response.prose.md (+1/-0) and does not fix the reported defect (the scanner still selects the wrong access method, so kagentz CT 105 and docker-vm CT 109 keep rendering as unreachable). The factual content is verified and useful (pct exec 105 sees loop0 59G while ssh root@kagentz sees the real 99G filesystem; CT 109 is a QEMU VM reached at 192.168.68.7), so the note will be folded into the substantive fix on task disk-gc-probe-false-unreachable-20260913, which must also make the reachability verdict deterministic and audit every rendered field against a live reading (the same run printed identical figures for abiba CT 100 and syslog-api CT 116). Closing rather than merging so the fix lands as one reviewable change.

Closed unmerged: the pre-delivery review returned FAIL on the correct ground - this is a documentation-only change in `disk-gc-threat-response.prose.md` (+1/-0) and does not fix the reported defect (the scanner still selects the wrong access method, so kagentz CT 105 and docker-vm CT 109 keep rendering as unreachable). The factual content is verified and useful (pct exec 105 sees loop0 59G while ssh root@kagentz sees the real 99G filesystem; CT 109 is a QEMU VM reached at 192.168.68.7), so the note will be folded into the substantive fix on task disk-gc-probe-false-unreachable-20260913, which must also make the reachability verdict deterministic and audit every rendered field against a live reading (the same run printed identical figures for abiba CT 100 and syslog-api CT 116). Closing rather than merging so the fix lands as one reviewable change.
abiba-bot closed this pull request 2026-09-13 04:47:14 +00:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SyslogSolution/prose-contracts#85