letta: placed state, a route, accepted keys, and a runtime that can log in #171
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: novox/mesh-catalog#171
Reference in New Issue
Block a user
The module named /var/lib/letta, a layout no definition may carry (ADR
0112); state is now a placed directory holding the bindings and secrets.
letta had no route, while the server it replaces is reached by its public
name (a workflow calls it there). It now contributes one for its
webendpoint; reach is the assignment's.
The server needs an OpenAI key for agents on OpenAI models, and nothing
gave it one:
openai-api-keyis an own-secret, accepted from theoperator (a key someone chose, not one the mesh can mint). The
server-password is accepted the same way where a server already has
clients. Both, and the database password inside LETTA_PG_URI, stay in the
server's environment: letta 0.6.x reads settings from the environment
only, and its startup.sh starts an embedded PostgreSQL unless
LETTA_PG_URI is set - the declared reason now says so.
The runtime's tools never authenticated: the client sent only a Bearer
token, and 0.6.x's --secure mode checks X-BARE-PASSWORD ("password ")
and answers 401 otherwise. The client now sends both. Its password comes
from the runtime config file (the key client.ts reads first) instead of an
env-file, so the runtime container no longer carries a secret in its
environment.
Image: the same 0.6.8 image, now pinned by the index digest ace runs
rather than its amd64 manifest.
Verified: catalogue tests with MESH_CATALOGUE set; tsc -p tsconfig.json in
the mesh-tools build image. Throwaway containers: a fresh 0.6.8 with its
embedded PG and two blocks made through the API; stopped, copied, dumped
from the copy; restored (schema letta + vector pre-made by the superuser,
--no-owner --role, search_path set on the database as the original had
it) into a grant-shaped database on the postgres module's pgvector image
(PG17); started in this shape: alembic finds nothing to do, both blocks
are there, a wrong password is refused with 401, and the patched client
lists agents. Test containers and data removed.
Depends on nothing in the controller (no
${bound:route:name}used). Prepared for ace's migration; nothing is assigned. Known gap, not fixable in this manifest: on a machine with no migrated data letta cannot start, because its tables need thevectorextension and a grant's owner may not create it (pgvector is not a trusted extension) - the postgres-database provision has no way to ask for an extension.The module named /var/lib/letta, a layout no definition may carry (ADR 0112); state is now a placed directory holding the bindings and secrets. letta had no route, while the server it replaces is reached by its public name (a workflow calls it there). It now contributes one for its `web` endpoint; reach is the assignment's. The server needs an OpenAI key for agents on OpenAI models, and nothing gave it one: `openai-api-key` is an own-secret, accepted from the operator (a key someone chose, not one the mesh can mint). The server-password is accepted the same way where a server already has clients. Both, and the database password inside LETTA_PG_URI, stay in the server's environment: letta 0.6.x reads settings from the environment only, and its startup.sh starts an embedded PostgreSQL unless LETTA_PG_URI is set - the declared reason now says so. The runtime's tools never authenticated: the client sent only a Bearer token, and 0.6.x's --secure mode checks X-BARE-PASSWORD ("password <it>") and answers 401 otherwise. The client now sends both. Its password comes from the runtime config file (the key client.ts reads first) instead of an env-file, so the runtime container no longer carries a secret in its environment. Image: the same 0.6.8 image, now pinned by the index digest ace runs rather than its amd64 manifest. Verified: catalogue tests with MESH_CATALOGUE set; tsc -p tsconfig.json in the mesh-tools build image. Throwaway containers: a fresh 0.6.8 with its embedded PG and two blocks made through the API; stopped, copied, dumped from the copy; restored (schema letta + vector pre-made by the superuser, --no-owner --role, search_path set on the database as the original had it) into a grant-shaped database on the postgres module's pgvector image (PG17); started in this shape: alembic finds nothing to do, both blocks are there, a wrong password is refused with 401, and the patched client lists agents. Test containers and data removed.