Create Letta pod #24

New issue

Open

opened 2026-08-20 21:08:18 -07:00 by tepichord · 0 comments

tepichord commented

2026-08-20 21:08:18 -07:00

Owner

This issue has no body, so there is nothing to plan yet. Two facts a plan for this pod
should start from, because otherwise it re-derives the whole tailnet problem.

Letta is the second consumer of the same shared inference gateway. That gateway is on
a different tailnet and shared as a machine share to a person, so no pod and no Tailscale
egress proxy can ever reach it directly: every device the operator creates is tagged, and
a machine share is not visible to a tagged device. The working path is a relay on the
libvirt host, and it is two issues:

Reach the tailnet-shared LLM gateway: relay on the libvirt host — the relay and the
host firewall rule that makes the port reachable at all.
Tailscale egress from the cluster: an ExternalName Service for the relay — the shared
egress-proxies ProxyGroup and the Service a pod dials.

What that means for this pod:

It dials a Service name, not lain-llm.tailc23d6.ts.net: the cluster resolves
nothing in that tailnet — NXDOMAIN for the whole zone.
It gets its own ExternalName Service in its own namespace, naming the same
shared egress-proxies ProxyGroup. One Service per consumer, because story 14 says a
preview must not inherit a live path to the inference box, and a shared Service in an
earlier layer would hand one to every preview namespace.
The gateway's API key is the only authentication on that path. It belongs in Vault
under this app's own prefix, read through a VaultAuth plus VaultStaticSecret
(docs/vault.md §4c-ter) — never a hand-run Secret, never a literal.
Nothing about the relay, the firewall rule or the ProxyGroup is this issue's to build.

Once there is a body, status/planning is the label that asks the planning agent to plan
it.

This issue has no body, so there is nothing to plan yet. Two facts a plan for this pod should start from, because otherwise it re-derives the whole tailnet problem. **Letta is the second consumer of the same shared inference gateway.** That gateway is on a different tailnet and shared as a machine share to a person, so no pod and no Tailscale egress proxy can ever reach it directly: every device the operator creates is tagged, and a machine share is not visible to a tagged device. The working path is a relay on the libvirt host, and it is two issues: - `Reach the tailnet-shared LLM gateway: relay on the libvirt host` — the relay and the host firewall rule that makes the port reachable at all. - `Tailscale egress from the cluster: an ExternalName Service for the relay` — the shared `egress-proxies` ProxyGroup and the Service a pod dials. **What that means for this pod:** - It dials a **Service name**, not `lain-llm.tailc23d6.ts.net`: the cluster resolves nothing in that tailnet — NXDOMAIN for the whole zone. - It gets **its own** `ExternalName` Service in **its own** namespace, naming the same shared `egress-proxies` ProxyGroup. One Service per consumer, because story 14 says a preview must not inherit a live path to the inference box, and a shared Service in an earlier layer would hand one to every preview namespace. - The gateway's **API key is the only authentication** on that path. It belongs in Vault under this app's own prefix, read through a `VaultAuth` plus `VaultStaticSecret` (docs/vault.md §4c-ter) — never a hand-run Secret, never a literal. - Nothing about the relay, the firewall rule or the ProxyGroup is this issue's to build. Once there is a body, `status/planning` is the label that asks the planning agent to plan it.