mirror of
https://github.com/agent-substrate/substrate.git
synced 2026-11-13 10:43:28 +08:00
Jeremy Alvis
41c5f01968
Fixes #997 ## Summary Give `ateapi` separate PostgreSQL connections for schema ownership and normal application access. Migrations and outbox partition maintenance use the owner connection, allowing application reads and writes to run with restricted permissions. - Each connection assumes its configured role with `SET ROLE`, keeping object ownership and grants separate from login credentials. - Configure owner and read/write connections through `ate-setup` and the installation manifests. - Default the schema to `substrate` and document provisioning for external PostgreSQL and Cloud SQL, including one IAM login with membership in both roles. - Keep bundled PostgreSQL using its existing `postgres` account and role for both pools. Restricted runtime access requires operator-provisioned roles. See `docs/postgres.md` for configuration details. ## Scope This is the base PR for two separate follow-ups: [file-based credentials](https://github.com/agent-substrate/substrate/pull/1979) and [automatic development database bootstrap](https://github.com/agent-substrate/substrate/pull/2025). Neither feature is included here. Operators provision external database roles, login memberships, schema ownership, and grants before startup. Table migrations still run automatically through the owner connection. The documented external database layout assumes a fresh database; this PR does not migrate existing table ownership or grants. Both connections remain inside `ateapi`, so this separates database permissions without isolating owner credentials from the application process. ## Validation - `env -u NO_COLOR make verify` passed. - PostgreSQL integration tests cover restricted runtime access, owner migrations and partition maintenance, and OpenFGA table permissions. - Installer tests cover bundled PostgreSQL, separate external logins, and Cloud SQL configuration.
ate-setup
Installs and tears down Agent Substrate on a Kubernetes cluster.
go run ./cmd/ate-setup [global flags] <command> [flags]
make build-ate-setup # builds bin/ate-setup
ate-setup is the installer. hack/install-ate.sh is a shim over it, kept so
that existing command lines and CI jobs keep working; it holds no install logic
of its own.
Installing a release
By default every image is built from the checkout with ko, which is what a
developer wants and what the shell installer always did. To install published
images instead, name the registry they were pushed to:
ate-setup deploy ate-system \
--image-repo registry.example.com/substrate \
--image-tag v0.0.0
Nothing is built and no registry is pushed to; the manifests still come from the checkout. Each reference is pinned to the digest its tag names, so the registry has to be readable from here as well as from the cluster.
commands.md— every command with itshack/install-ate.shequivalent.differences.md— where the Go port deliberately behaves differently from the shell scripts it replaced, and what was reproduced exactly.cli-diff.md— what ahack/install-ate.shuser can observe after the switch.