Skip to content

Fix FerretDB tenant provisioning on 0.9.0 - #142

Merged
sciabarracom merged 6 commits into
apache:0.9.0from
miki3421:fix-0.9.0-ferretdb-provisioning
Oct 22, 2026
Merged

sciabarracom merged 6 commits into
apache:0.9.0from
miki3421:fix-0.9.0-ferretdb-provisioning

Conversation

@miki3421

@miki3421 miki3421 commented Oct 19, 2026 •

Copy link
Copy Markdown
Contributor

FerretDB tenant provisioning in 0.9.0 passes a name such as tenant_ferretdb to the PostgreSQL script renderer as a Kubernetes namespace. The namespace validator correctly rejects the underscore, so both user creation and deletion fail before SQL execution. This failure is reproducible in the original 0.9.0 CI run 38893750250.

Pass the actual Kubernetes namespace to the renderer while preserving the existing _ferretdb SQL database and role names. Select the PostgreSQL primary explicitly, validate SQL identifiers with the existing database-name validator, and report provisioning success only after connection metadata has been produced. FerretDB explicitly validates the actual Kubernetes namespace before calling the PostgreSQL renderer, preserving that boundary when combined with a renderer that accepts SQL identifiers. Component versions, tenant credentials and SQL naming remain unchanged.

Validation:

  • 9 focused provisioning regressions and all 23 shared regression tests passed locally. The create-user regression fails against the original implementation and passes with this fix.
  • Tests exercise the actual namespace validator and script renderer with Kubernetes/filesystem boundaries mocked, including create/delete, primary selection, invalid names, SQL failure and unavailable connection metadata. Both create and delete reject an invalid Kubernetes namespace before calling the renderer or executing SQL; these boundary regressions fail on the preceding implementation. The filesystem mock includes chmod so the tests remain compatible with protected SQL files. The exact updated regression file also passes all 79 tests against the patched local baseline.
  • The Kind integration test now verifies the actual SQL database, login role and CONNECT/CREATE grants and checks that both database and role disappear on deletion. Its SQL probe was checked read-only in the existing K3s lab; full provisioning validation runs in the isolated CI cluster.
  • CI runs the regression suite and rejects integration failures. The two known baseline failures are tolerated only while the corresponding test script matches its original 0.9.0 Git blob exactly. This PR changes its integration script, so its test must pass despite the legacy task itest runner's exit-code behavior. The workflow change is identical in both independent PRs; after both scripts are updated, neither failure can be downgraded to a warning.

This PR is independent of the Redis and etcd/Milvus security backports. The separate runtime-preloader test correction addresses the other baseline CI failure. Previous CI passed on 5c3c9e5. Current-head CI: Check run 39312476510 passed on 6f8a498: all 23 regression tests, the unit-test step and the final integration gate passed. The actual FerretDB integration test reports OK. The only previously remaining warning is the unchanged original tests/kind/runtimes_preloader_test.ipy, addressed by the companion PR.

@sciabarracom
sciabarracom self-requested a review October 20, 2026 12:43
@sciabarracom
sciabarracom merged commit bd24b2b into apache:0.9.0 Oct 22, 2026
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants