a pod that terminates TLS could not reach itself (v0.4.5)
0.4.3 got placement working on a pod: it resolved the model and minted an
attach lease, which it had never managed before. Then surya said:
SURYA_INFERENCE_URL=http://127.0.0.1:8000/v1/ocr/attach/<lease>/v1
is not reachable at /health
...about an address the pod was answering perfectly well. A pod on the
direct path serves HTTPS on its ONLY port, and an OCR engine there is a
SUBPROCESS: it attaches by URL and goes through the socket like any other
client. self_base() handed it `http://`, so it probed a plain request at a
TLS listener.
Fixed with verification ON end to end, not off:
* the leaf certificate now carries DNS:coderai-pod, DNS:localhost,
IP:127.0.0.1 and IP:::1. It had one SAN, `coderai-pod`, that the comment
said was "never checked" -- true for the orchestrator, which reaches a
pod by a bare IP with the hostname check off. A pod reaching ITSELF has
no such excuse, so it uses a name the certificate actually holds.
* boot.sh maps 127.0.0.1 coderai-pod and exports
CODERAI_SELF_BASE=https://coderai-pod:8000; the plain-HTTP case (behind
the RunPod proxy) exports the loopback http base explicitly instead of
relying on a default.
* the CA's PUBLIC certificate now travels with the leaf, appended to
CERTIFI'S ROOTS into one bundle. That order is not cosmetic: a bundle
that lost the public roots would break every HuggingFace download on the
pod, which is worse than the bug. Exported only once built and non-empty,
and it says so plainly when it cannot be.
This covers chandra and olmOCR too -- in served mode they attach through
the same gateway URL from the main venv, so one trust store serves all
three.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM
Showing
Please
register
or
sign in
to comment