feat(coldfront): control-plane support for ColdFront (single-node)

[dpage]

Overview

The control-plane side of ColdFront (transparent Postgres→Iceberg data tiering), consuming the lakekeeper service the saas control plane sends. This is the single-node scope and one of several per-repo PRs for the feature; it is not end-to-end usable alone (see Dependencies & deferred).

What's included

• lakekeeper service type — image (quay.io/lakekeeper/catalog), launch recipe (serve, port 8181), config resource, validator, Goa enum; follows the MCP recipe in docs/development/supported-services.md.
• Catalog Postgres via external URL — Lakekeeper's catalog DB is supplied by Cloud as a configurable connection URL; the control plane does not provision it (ColdFront forbids co-locating the catalog on a data node). migrate→serve is enforced as a resource dependency; missing catalog config fails loudly.
• Post-deploy bootstrap — idempotent Lakekeeper REST warehouse creation (bootstrap→warehouse→namespace) with the correct S3 storage-profile (flavor/path-style-access/key-prefix, verified against the ColdFront docs), and coldfront.set_storage_secret/_azure on the database. The object-store credential is bound as query arguments (never interpolated into SQL, never logged); signatures match coldfront--1.0.sql.
• Tiering-job scheduling — archiver/partitioner/compactor scheduled via the existing gocron/etcd scheduler, each run single-pass in the primary node's Postgres container with its exit code captured (recorded as task.TypeTiering, following the pgBackRest schedule precedent). The tables to tier are resolved by the binaries from the DB registry (coldfront.partition_config, customer-driven), so no table list is passed. The archiver's "no tables configured" exit is treated as benign.
• Multi-node guard — enabling ColdFront on a multi-node database is rejected at validation (and defence-in-depth at plan time), pending the deferred mesh work.

Ordering & safety

migrate → serve (health-gated) → REST bootstrap (blocking, after healthy serve) → set_storage_secret (after the coldfront extension exists) → scheduled jobs. All enforced by real resource dependencies. Credentials live in etcd resource state / job args exactly as existing services (RAG keys, ServiceSpec.Config) do — no new plaintext-at-rest or plaintext-in-logs exposure. Everything is runtime-gated by the (unpublished) ColdFront Postgres image, so no unsafe partial state is reachable today.

Dependencies & deferred (follow-ups — not in this PR)

• saas contract expansion (blocks real use): the saas side currently sends only warehouse/path_prefix/credential in the lakekeeper ServiceSpec.Config. For this to function it must also supply catalog_db_url, pg_encryption_key, and the store coordinates provider/bucket/region/endpoint (all resolvable from the coldfront_store record). The control plane fails loudly where these are absent.
• Multi-node mesh (snowflake.node) reconciliation: ColdFront's bakery requires snowflake.node = hashtext(spock_node_name)&1023, which conflicts with the control plane's ordinal-based snowflake.node (Spock/lolor). Solvable in principle (CP's snowflake.node value is consumed only by the snowflake/lolor extensions), but the clean fix needs a CP + ColdFront-author decision (likely a small ColdFront upstream change) plus a node-name hash-collision check. Hence single-node-first here.
• ColdFront-enabled Postgres image (Phase 0) and confirmation of the pinned Lakekeeper image tag v0.9.0 (currently a plausible placeholder).
• Azure ADLS storage-profile mapping is a placeholder pending the saas azure coordinates; the coldfront/localhost DSN used by the tiering binaries is an implicit contract with the image; and a ColdFront upstream benign-exit-code would let us stop keying the archiver's empty-run detection on log text.

Testing & review

Built task-by-task with TDD; unit-tested throughout (exit-code capture, REST bootstrap ordering/idempotency, per-provider set_storage_secret, fail-loud config, multi-node rejection). Contract details (SQL signatures, S3 warehouse profile) were verified against the pgEdge/coldfront source. go build ./... clean; the Goa regen is minimal (canonicalised via the pinned goa v3.23.4 + yamlfmt v0.21.0 under go1.25.8). Real end-to-end awaits the ColdFront image.

[codacy-production]

Not up to standards ⛔

🔴 Issues 1 critical · 13 medium

Alerts:
⚠ 1 issue (≤ 0 issues of at least critical severity)
⚠ 1 issue (≤ 0 issues of at least minor severity)

Results:
14 new issues

Category	Results
Security	1 critical (1 false positive)
Complexity	13 medium

View in Codacy

🟢 Metrics 184 complexity · 36 duplication

Metric	Results
Complexity	184
Duplication	36

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}