Exstream CE Helm install stalls at the design schema job

Symptom

helm install with --wait --timeout 30m0s ends with INSTALLATION FAILED after exstream-design-schema-job fails or times out. The deployment then reports 0 out of 1 expected pods are ready.

A revealing detail when manual schema mode is involved: the target database contains only databasechangelog and databasechangeloglock. Liquibase created its own bookkeeping tables and then nothing else, which means the migration machinery started and the actual schema work failed.

Cause

The evidence points at schema initialization, not Helm rendering. The chart deploys fine; the design schema job cannot complete its migrations against the configured databases.

In the described multi-schema setup, the expected application schemas were exd_system, exd_tenant, exo_system, and exo_tenant. One community warning worth repeating: do not use public as both dasdb.externalDb.schema and orcdb.externalDb.schema. Note that the original case ended without a confirmed final fix, so treat this as diagnostic direction rather than a guaranteed resolution path.

Fix

Start where the failure actually is:

1. Read the logs of the failed exstream-design-schema-job pod. This is the primary evidence; everything else is inference.
2. Verify database host, credentials, permissions, schema names, and network reachability from inside the pod, not from your workstation.
3. If auto schema management is disabled, run the release-matched Liquibase scripts for each required schema, and confirm the run creates more than the two Liquibase bookkeeping tables.
4. Compare your values file and bootstrap configuration (including the otds.bootstrap.license settings) against the CE 24.2 installation guide.

Do not extend the Helm timeout to get past the failure. A migration that fails in 30 minutes will fail in 60; the longer timeout only delays the same diagnosis and can leave a half-initialized database behind.

Do not accept a partially initialized schema

Mark the deployment unresolved until the schema job succeeds and all expected services report ready. Pods starting against an incomplete schema move the failure into runtime, where it is harder to trace back to installation.