Repository navigation
feat(managed-bootstrap): the migration owner declares its identity and its server's authority - #207
Merged
antoinetoussaint-byte merged 2 commits intoOct 29, 2026
Conversation
…d its server's authority The follow-up #205 named and deliberately left: bootstrap.Options grew an external-identity declaration and a server trust anchor, but the command could not see them, because the root module pins a published libs/go rather than replacing it with the tree. #206 is on main, so the pin moves and the command reads the two declarations. Delivered as configuration beside the connection they describe, never as flags. A Job's command line is readable by anything in its pod, and these two are the deployment's statement about where this database is. Neither is a secret — an issuer names who mints the credential, and a certificate authority is public information — while a credential minted from the issuer is, which is why it never appears here and is fetched per connection instead. Absent means the password-authenticated behaviour every existing deployment has. This is what lets migrations run against a managed server at all: the database exists but its schema and its application roles do not, and creating a login in the cloud grants CONNECT and nothing else — the in-database roles and grants are the migration owner's work. Verified: the root module builds and vets, and the bootstrap parity suite passes against a real Postgres. One of its four parallel subtests failed first on `all predefined address pools have been fully subnetted` — this machine had 30 Docker networks from concurrent worktrees, and the subtest passes alone. That flake is the environment, not this change. Not verified: no migration has run against a managed instance. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`go get` adds the new version's hashes without removing the old module version's, and CI's tidiness gate runs `go mod tidy` and compares — so the commit has to carry what tidy produces, not what go get leaves. Three stale lines for the previous libs/go pseudo-version. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
antoinetoussaint-byte
enabled auto-merge (squash)
October 29, 2026 03:47
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The follow-up #205 named and deliberately left undone.
#205 gave
bootstrap.Optionsan external-identity declaration and a server trust anchor, butcmd/managed-bootstrapcould not see them: the root module pins a publishedlibs/gorather than replacing it with the tree, and adding areplacewould make the root build against local sources while its release builds against the pin — two states nobody can reproduce. #206 is on main, so the pin moves and the command reads the declarations.Why it matters now
This is what lets migrations run against a managed server at all. A managed database can exist with no schema and no application roles, and creating a login in the cloud grants
CONNECTand nothing else — infra's own module says so explicitly: the in-database roles and grants are the cluster interior's job. That job is this command.The two reads
Configuration beside the connection they describe, never flags. A Job's command line is readable by anything in its pod. Neither value is a secret — an issuer names who mints the credential, and a certificate authority is public information — while a credential minted from the issuer is, which is why it appears nowhere here and is fetched per connection instead. Absent means the password-authenticated behaviour every existing deployment has.
Classification
Fix, completing #205 at the place that owns it, with no new mechanism: the resolution table and the anchor parse are the library's, exported for this caller in #205 precisely so there would be one vocabulary rather than a copy here.
Verified
Root module builds and vets. The bootstrap parity suite passes against a real Postgres.
One of its four parallel subtests failed on the first run with
Error response from daemon: all predefined address pools have been fully subnetted— this machine had 30 Docker networks from concurrent worktrees. The subtest passes alone. That flake is the environment, not this change, and it is worth knowing about because a reviewer on a busy machine will hit it too.Not verified
No migration has run against a managed instance. The path from here is an identity for the migration owner in the target cell and a Job that carries these two values.