Files
cc-ci/machine-docs/JOURNAL-pvcheck.md
autonomic-bot 3df0ee154d
Some checks failed
continuous-integration/drone/push Build is failing
claim(pvcheck-M1): control plane and routing verified post-proxy-recreation
proxy subnet: 10.10.0.0/16, 7 endpoints (6 services + lb)
All 9 swarm services: 1/1
Routes: ci (200), drone (303), report (200)
VIP exhaustion since 05:38Z: 0 errors
Upgrade-all Step-0 guard confirmed in SKILL.md §0
[A2] SKILL.md stale description fixed (orchestrator commit 84e13a7)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-13 06:00:03 +00:00

48 lines
2.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# JOURNAL — phase pvcheck (post-proxy verification)
Builder-private reasoning and working notes. Anti-anchoring: Adversary reads STATUS for claims, not this file.
---
## 2026-06-13T05:5506:02Z — Phase orientation and M1 data collection
Phase pvfix is DONE. Entered pvcheck. No phase files existed yet — the Adversary had proactively created REVIEW-pvcheck.md and BACKLOG-pvcheck.md with a baseline probe at 05:56Z.
**Adversary baseline findings (from REVIEW-pvcheck.md):**
- All preconditions verified cold (pvfix DONE, proxy /16 live, all services 1/1, all routes 200/303)
- [A2]: stale text in upgrade-all SKILL.md — "per-run safety net until that lands" (fix: proxy /16 HAS landed)
**My verification runs:**
```
$ ssh cc-ci 'docker network inspect proxy --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}, Endpoints: {{len .Containers}}"'
10.10.0.0/16, Endpoints: 7
$ curl -sk -o /dev/null -w "%{http_code}" https://ci.commoninternet.net/ → 200
$ curl -sk -o /dev/null -w "%{http_code}" https://drone.ci.commoninternet.net/ → 303
$ curl -sk -o /dev/null -w "%{http_code}" https://report.ci.commoninternet.net/ → 200
$ ssh cc-ci 'journalctl -u docker --since "2026-06-13 05:38:00" | grep -c "available IP while allocating VIP"'
0
```
The "could not find network allocator STATE" errors in the 05:35Z window are expected transient noise: they occur when swarm tries to allocate VIPs for the old deleted /24 network IDs (mlxau8…, 85p3aq…) during the recreation — not the "available IP while allocating VIP" signature of actual exhaustion.
**A2 fix applied:**
- Edited `/srv/cc-ci-orch/.claude/skills/upgrade-all/SKILL.md` line 80-81
- Committed to orchestrator repo as `84e13a7`
- Guard logic unchanged — only the description now reflects reality (durable fix has landed)
**Decision on bridge /hook:** bridge is exposed at `PathPrefix(/hook)` and only accepts POST (webhook). A GET to `/hook` returns 404 — expected; health is confirmed via service logs showing the poller running and commenting on repos.
**M1 claim:** All control-plane facts documented. Claiming M1 now. Will work on M2 while awaiting verdict.
---
## 2026-06-13T06:02Z — M2 planning
M2 requires:
1. Real recipe CI run through proxy — will use a small enrolled recipe like `hedgedoc` or `cryptpad` if a !testme PR exists, or trigger via the harness directly
2. Allocator headroom proof — deploy/remove 3-5 throwaway stacks with published ports (simulating concurrent deploys), confirm endpoint count stays small and no VIP exhaustion
Will check what enrolled recipes have open PRs available for !testme first.