feat: update iron-proxy to 0.42.0-rc.8 with single multiplexed pg listener#426
Open
mslipper wants to merge 2 commits into
Open
feat: update iron-proxy to 0.42.0-rc.8 with single multiplexed pg listener#426mslipper wants to merge 2 commits into
mslipper wants to merge 2 commits into
Conversation
…tener Bump iron-proxy to 0.42.0-rc.8. PG DSNs are now fully managed by iron-control and multiplexed through a single listener that routes by database name, replacing the per-upstream listener model (one sequential port and per-foreign-id IRON_PROXY_PG_<FOREIGN_ID>_* env vars each). api-rs now binds one port with a single random username/password per sandbox, set via the deploy-level IRON_PROXY_PG_LISTEN / IRON_PROXY_PG_CLIENT_USER / IRON_PROXY_PG_CLIENT_PASSWORD env vars. Each upstream still gets its own sandbox DSN env var, all pointing at the shared listener and credential and differing only by database. Collapse the chart's pgPortRangeStart/End into a single pgPort.
Bake every sandbox's Postgres DSN env vars from the tools' declared pg_dsn fragments instead of the per-principal iron-control effective config. Warm sandboxes are created under the roleless bootstrap principal, so the old per-principal path left them with no DSN env and no PG listener, and neither could be added after claim without restarting the pod. Since iron-proxy now multiplexes every upstream through a single listener, the DSNs differ only by database (declared verbatim in each tool's pyproject), so the catalog is fully derivable at startup. api-rs stamps the per-sandbox proxy host and client credential at create; the reassignable proxy enforces per-principal access at runtime by routing only the claimed principal's granted databases.
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
1 participant
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.
Updates iron-proxy to 0.42.0-rc.8. PG DSNs are now fully managed by iron-control and multiplexed through a single listener that routes by database name, replacing the per-upstream listener model (each upstream previously got its own sequential port and per-foreign-id
IRON_PROXY_PG_<FOREIGN_ID>_*env vars).api-rs now configures a single PG listener on one port with a single random username/password generated per sandbox, passed via the deploy-level
IRON_PROXY_PG_LISTEN,IRON_PROXY_PG_CLIENT_USER, andIRON_PROXY_PG_CLIENT_PASSWORDenv vars. Each upstream still reaches the sandbox as its own DSN env var, but they all point at the shared listener and credential and differ only bydatabase.databaseremains required on pg_dsn secrets (the routing key). The chart'spgPortRangeStart/pgPortRangeEndcollapse into a singlepgPort.Building on that single listener, sandbox PG DSN env vars are now derived from the static tool fragment catalog (each tool's declared
pg_dsnname + database) instead of the per-principal iron-control effective config. The shape is fixed at startup, so every sandbox — including warm-pool sandboxes created under the roleless bootstrap principal — is born with the full DSN set and a live listener; the reassignable proxy still enforces per-principal access at runtime by routing only the claimed principal's granted databases. This closes the gap where warm sandboxes were claimed with no PG env and no listener, which couldn't be fixed after claim without restarting the pod. To support this,postgres_listenersretains the declared DSN env var name/database on the fragment, and infra + tool fragments are now handed to the k8s backend.