refactor(flyte-binary): consolidate DB config to runs.database

[pingsutw]

Tracking issue

N/A — chart cleanup.

Why are the changes needed?

The flyte-binary chart configured the database in two places:

• flyte-core-components.runs.database — what the unified binary actually
  connects through (runsconfig.GetConfig().Database in manager/cmd/main.go,
  registered under the runs config section).
• configuration.database — a separate top-level block that the unified binary
  does not read. It only fed the waitForDB init container, the
  002-database.yaml config file (a top-level database: section read only by
  the standalone runs/cache_service cmd binaries, never the unified binary),
  and an optional password Secret.

Keeping both invites drift (the two could point at different DBs) and is
confusing. This consolidates to a single, flat source of truth:
configuration.database. Users set the DB in one conventional place, and the
chart maps it to runs.database — the path the unified binary actually reads —
at render time.

What changes were proposed in this pull request?

• values.yaml — removed the flyte-core-components.runs.database block.
  configuration.database is now the single DB config (with maxIdleConnections,
  maxOpenConnections, connMaxLifeTime, and the postgres sub-block).
• configmap.yaml — 002-database.yaml now renders configuration.database
  under runs.database (instead of the old top-level database:), so the
  unified binary reads it at runsconfig.GetConfig().Database. The config dir is
  loaded via --config /etc/flyte/config.d/*.yaml, so this file deep-merges with
  the runs: section in 000-core.yaml and the password in
  012-database-secrets.yaml. The password field is stripped before toYaml
  (deepCopy + unset) so it is never written to the ConfigMap in plaintext —
  it is supplied via the Secret instead.
• config-secret.yaml — the optional DB-password Secret
  (012-database-secrets.yaml) now reads configuration.database.postgres.password
  and renders it as runs.database.postgres.password.
• deployment.yaml — the waitForDB init container derives its pg_isready
  target from configuration.database.postgres, so it waits on exactly the DB
  the binary connects to.

configuration.database remains the single, required DB config.

How was this patch tested?

• helm template renders cleanly both with a values override and with bare
  chart defaults.
• Verified 002-database.yaml renders runs.database and that the password is
  never present in the ConfigMap (0 plaintext occurrences) while still being
  carried by 012-database-secrets.yaml.
• Verified the wait-for-db init container resolves to the configured
  configuration.database host/port/user.
• helm lint passes.

Labels

changed

Check all the applicable boxes

• I updated the documentation accordingly.
• All new and existing tests passed.
• All commits are signed-off.

[Copilot]

Pull request overview

This PR cleans up the flyte-binary Helm chart by removing the unused configuration.database block and consolidating all DB configuration under flyte-core-components.runs.database, ensuring the init-container and optional DB-password Secret target the same database the unified binary uses.

Changes:

• Removed the unused configuration.database defaults from values.yaml.
• Updated the wait-for-db init container to derive pg_isready parameters from flyte-core-components.runs.database.postgres.
• Removed the standalone 002-database.yaml config render and moved the optional password Secret to read from runs.database.postgres.password.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
charts/flyte-binary/values.yaml	Removes configuration.database defaults and documents the consolidated DB config location.
charts/flyte-binary/templates/deployment.yaml	Points the wait-for-db init container at runs.database.postgres fields.
charts/flyte-binary/templates/configmap.yaml	Removes 002-database.yaml generation (standalone-binary-only config).
charts/flyte-binary/templates/config-secret.yaml	Reads optional DB password from runs.database.postgres.password to generate 012-database-secrets.yaml.

Comments suppressed due to low confidence (1)

charts/flyte-binary/templates/deployment.yaml:80

• If flyte-core-components.runs.database.postgres is missing (or overridden to a non-postgres config), this with block renders no args for sh -ec, which will crash the init container in a non-obvious way. Prefer failing the template render with a clear error (or require users to provide deployment.waitForDB.args).

            {{- with (index .Values "flyte-core-components" "runs" "database" "postgres") }}
            - |
              until pg_isready \
                -h {{ tpl .host $ }} \
                -p {{ .port }} \

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

Comments suppressed due to low confidence (1)

charts/flyte-binary/templates/deployment.yaml:82

• 002-database.yaml templates the entire configuration.database block via tpl, which means postgres.username can be templated in the rendered config. The wait-for-db init container currently uses .username without tpl, which can lead to it waiting with a different username than the binary config if a user supplies a templated value. Consider templating the username here as well for consistency.

              until pg_isready \
                -h {{ tpl .host $ }} \
                -p {{ .port }} \
                -U {{ .username }}
              do

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

charts/flyte-binary/templates/deployment.yaml:86

• If configuration.database.postgres is empty/omitted and deployment.waitForDB.args is not set, the with block produces no list items and args: becomes null, which is invalid for a container spec. Consider failing fast with required (or providing an explicit fallback) so Helm doesn’t render an invalid manifest.

            {{- with .Values.configuration.database.postgres }}
            - |
              until pg_isready \
                -h {{ tpl .host $ }} \
                -p {{ .port }} \
                -U {{ .username }}
              do
                echo waiting for database
                sleep 0.1
              done
            {{- end }}

docker/devbox-bundled/manifests/complete.yaml:7812

• This rendered manifest’s inline runs.database.postgres block uses dbName/user keys, which don’t match Flyte’s expected dbname/username keys for Postgres config. If this file is used directly, the override may be ignored and the service can end up using the default DB settings instead of the intended runs DB.

        ephemeralStorage: 0
        gpu: 0
        memory: 1Gi
      limits:
        cpu: 0

[machichima]

Should we also update

flyte/charts/flyte-binary/README.md

Lines 46 to 52 in 9c41e6e

	| configuration.database.dbname | string | `"flyte"` | |
	| configuration.database.host | string | `"127.0.0.1"` | |
	| configuration.database.options | string | `"sslmode=disable"` | |
	| configuration.database.password | string | `""` | |
	| configuration.database.passwordPath | string | `""` | |
	| configuration.database.port | int | `5432` | |
	| configuration.database.username | string | `"postgres"` | |

[machichima]

I think this is still supported? Should we add it back?

[pingsutw]

Good catch — yes, it's still supported. passwordPath is read by the binary (flytestdlib/database/config.go: PostgresConfig.PasswordPath, with "Either Password or PasswordPath must be set"), and the legacy flat database.passwordPath is still mapped into Postgres.PasswordPath in GetConfig().

Added it back under configuration.database.postgres.passwordPath in 689f63a. It's the file-based password option (point at a file you mount yourself via deployment.extraVolumes/extraVolumeMounts, e.g. from an external secret manager) — distinct from password, which the chart turns into a managed Secret; the two are mutually exclusive. It flows straight through to runs.database.postgres.passwordPath via the existing configmap rendering (only password is stripped), so no template change was needed.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.

Comments suppressed due to low confidence (1)

charts/flyte-binary/templates/deployment.yaml:81

• If deployment.waitForDB.args is not set and configuration.database.postgres is missing (e.g., users still providing the legacy configuration.database.host/port/username keys), this renders an initContainer with sh -ec but no command string under args, causing pod startup failure with a confusing shell error. Consider failing fast with a clear message when configuration.database.postgres is absent.

            {{- with .Values.configuration.database.postgres }}
            - |
              until pg_isready \
                -h {{ tpl .host $ }} \
                -p {{ .port }} \
                -U {{ .username }}