OpenMetadata Configuration

ChartVersion3.0.1TypeapplicationAppVersion1.12.4

CompatibilityKubernetes1.32+OpenShift4.19+Rancher2.10.x+

Feature SupportLDAPsupportedExternal DBsupportedIngresssupportedGateway APIsupported

This page covers the installation and configuration of OpenMetadata via the tdp-openmetadata chart: prerequisites, OCI installation, main parameters, access and uninstallation. Authentication, LDAP and the datasources job are detailed in the related pages. Database (PostgreSQL) is documented on this page.

What is OpenMetadata?

The OpenMetadata platform is a data catalog and governance solution.

In practical terms, it is where you register all your organization's data assets — ClickHouse tables, Kafka topics, Superset dashboards, Airflow pipelines — and get a unified view of who created them, what they mean, who uses them and how they relate to each other.

In TDP Kubernetes, OpenMetadata addresses the following need: with so many components (Trino, ClickHouse, Kafka, Airflow, Superset), it is hard to know where a specific piece of data lives, what it means and whether it is still trustworthy.

OpenMetadata centralizes data discovery, cataloging and documentation.
This makes it easier to find the origin, context and owners of data in multi-engine environments.
The catalog does not replace pipeline or SLA monitoring, but it organizes metadata and links between assets registered on the platform.

Learn more

See OpenMetadata — Concepts for a comprehensive overview of the tool, its architecture and how it works.

Helm value structure

OpenMetadata server values go under the tdp-openmetadata: key. External services, automations and external exposure settings use separate top-level blocks:

• tdp-openmetadata: — server, image, Ingress, database, search backend, RBAC.
• externalServices: — reference to external PostgreSQL (hooks and admin password).
• datasourcesIntegration: — post-install job for automatic TDP datasource registration.
• gatewayApi: — HTTPRoute and Gateway configuration for Gateway API exposure.
• TDP-Settings: — selects the HTTP/HTTPS exposure mode (Ingress or Gateway API).
• openshift: — SCC configuration for OpenShift environments.

TDP-Settings:
  gateway:
    ingress:
      enabled: false
    gatewayApi:
      enabled: false

tdp-openmetadata:
  openmetadata:
    config:
      database:
        dbScheme: "mysql"

externalServices:
  postgresql:
    enabled: false

Exposure control key

This chart uses the TDP-Settings.gateway key to control which HTTP exposure mode is active. Enable only one: Ingress or Gateway API.

Deployed components

Component	Description
OpenMetadata Server	API and web catalog interface
MySQL (internal default)	OpenMetadata metadata database
OpenSearch	Search backend for discovering data assets
K8s ingestion Jobs	Default pipeline executor (no Airflow dependency)
Datasources Job (optional)	Automatically registers TDP services after installation

Chart automations

The tdp-openmetadata chart includes the following automations:

• Dynamic URLs — API endpoints and JWKS are automatically derived from the release name and namespace, without manual configuration.
• Credential bootstrap — the admin user (admin@open-metadata.org) is created automatically; the password is configurable via values and shown in the helm install output (NOTES).
• Automatically generated Secrets — bundled dependencies (MySQL, OpenSearch) receive Kubernetes Secrets generated by the chart itself.
• Uninstall cleanup — a post-delete Job automatically removes PVCs, Secrets and ConfigMaps left by the release when running helm uninstall.

Overview

Property	Value
Chart	tdp-openmetadata
OpenMetadata version	1.12.4
Chart version	3.0.1
Registry (OCI)	oci://registry.tecnisys.com.br/tdp/charts/tdp-openmetadata

Related pages

Page	Content
Integrations — OpenMetadata	Datasources registration job, modular values files, per-service configuration and pipeline execution
Security — OpenMetadata	Basic and LDAP authentication, access control and best practices
External exposure	Ingress and Gateway API for OpenMetadata

Prerequisites

• Kubernetes 1.32+, Red Hat OpenShift 4.19+ or Rancher Manager 2.10.x+.
• Helm 3.2.0+.
• StorageClass available in the cluster for persistent volumes.

Installation

Installation (OCI)

Installation on Kubernetes

The following command creates the release in the indicated namespace. Use --wait --wait-for-jobs to wait for the completion of post-install Jobs before returning — without these flags, Helm may report success before the Jobs finish.

Terminal input

helm install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/tdp-openmetadata \
  -n <NAMESPACE> --create-namespace \
  --wait --wait-for-jobs --timeout 10m

Installation on OpenShift

On OpenShift, ingestion Jobs run with runAsUser: 0 (root) to install dependencies via pip. Therefore they require the SCC (Security Context Constraint) anyuid. Set openshift.enabled: true so the chart automatically configures the required RoleBinding.

Terminal input

helm install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/tdp-openmetadata \
  -n <NAMESPACE> --create-namespace \
  --set openshift.enabled=true \
  --wait --wait-for-jobs --timeout 10m

Or via a values file:

values-openshift.yaml

openshift:
  enabled: true

Terminal input

helm install <RELEASE_NAME> oci://registry.tecnisys.com.br/tdp/charts/tdp-openmetadata \
  -n <NAMESPACE> --create-namespace \
  -f values-openshift.yaml \
  --wait --wait-for-jobs --timeout 10m

When openshift.enabled: true is set, the chart creates a RoleBinding that adds the following ServiceAccounts to the anyuid SCC:

ServiceAccount	Usage
openmetadata-ingestion	OpenMetadata ingestion Jobs
<RELEASE_NAME>-openmetadata-sa	Datasources integration Job

After creating a data service in the OpenMetadata UI, verify that Jobs started correctly:

Terminal input

oc get jobs -n <NAMESPACE>
oc get pods -n <NAMESPACE>

Main parameters

Main parameters

The table below highlights keys that define whether the stack starts, which image runs, how the server reaches MySQL and OpenSearch, whether there is Ingress, and whether external PostgreSQL or the datasources job is in play. For the full parameter list, run helm show values for the installed chart version.

Parameter	Description	Default
tdp-openmetadata.enabled	Enable OpenMetadata deployment	true
tdp-openmetadata.image.tag	Server image tag	1.12.4
TDP-Settings.gateway.ingress.enabled	Enable Ingress for external exposure	false
TDP-Settings.gateway.gatewayApi.enabled	Enable Gateway API for external exposure	false
tdp-openmetadata.openmetadata.config.database.dbScheme	Metadata database scheme	mysql
tdp-openmetadata.openmetadata.config.database.host	Metadata database host	tdp-openmetadata-mysql
tdp-openmetadata.openmetadata.config.elasticsearch.searchType	Search backend type	opensearch
tdp-openmetadata.openmetadata.config.elasticsearch.host	Search backend host	tdp-openmetadata-opensearch
tdp-openmetadata.openmetadata.config.pipelineServiceClientConfig.type	Pipeline execution mode: k8s or airflow	k8s
externalServices.postgresql.enabled	Use external PostgreSQL instead of bundled MySQL	false
datasourcesIntegration.enabled	Post-install/upgrade job that registers external services	false
openshift.enabled	Configure anyuid SCC for OpenShift environments	false

Individual datasource blocks are disabled by default even when the job is active. Enable only the services whose connection data and credentials are configured.

Other keys: consult the helm show values output for the package version you are using.

Configuration details

Integration

OpenMetadata plays a different role from other TDP components. While Ozone, ClickHouse and Trino are consumed by other tools (which read or write data to them), OpenMetadata is the one that catalogs and governs the others: it discovers, documents and connects data assets across the entire platform.

This means OpenMetadata integration is, in practice, connecting the catalog to each of the other components in the stack:

Registered component	Service type in the catalog
Trino	Database Service
ClickHouse	Database Service
Superset	Dashboard Service
Airflow	Pipeline Service
Kafka	Messaging Service

The tdp-openmetadata chart automates this registration through a post-install/upgrade Job (datasourcesIntegration), which authenticates against the OpenMetadata API and creates the enabled services. You choose which components to register — each has its own configuration block and can be enabled or disabled individually.

In addition to datasource registration, the chart also supports replacing internal MySQL with external PostgreSQL (tdp-postgresql). See the Database (PostgreSQL) section on this page.

For modular values files, per-service configuration, development and production examples, verification and pipeline execution, see Integrations — OpenMetadata.

Pipeline execution

OpenMetadata can run ingestion pipelines in two modes: k8s (default), using Kubernetes Jobs, or airflow, with REST integration with the Airflow service.

The behavior is controlled by pipelineServiceClientConfig.type. Parameters per mode and Airflow requirements are in Integrations — OpenMetadata.

Database (PostgreSQL)

By default, OpenMetadata uses a bundled MySQL to store its metadata. This section describes how to replace it with a PostgreSQL database managed by the tdp-postgresql chart.

What happens when enabled

When externalServices.postgresql.enabled: true is set, the chart automatically runs the following sequence:

1. MySQL disabled — no MySQL pod is created; MySQL PVCs are not provisioned.
2. Automatically generated password — a random password is created for the openmetadata_user user and saved in a Kubernetes Secret called openmetadata-postgresql-secrets.
3. pre-install/pre-upgrade Job — a Job creates the openmetadata_db database and the openmetadata_user in PostgreSQL, using the admin password from tdp-postgresql (Secret automatically generated by that chart on install).
4. OpenMetadata connects to PostgreSQL — after the Job completes, the OpenMetadata server starts and connects to PostgreSQL using the credentials generated in the previous step.

The Secrets involved in this integration are:

Secret	Created by	Role
<POSTGRESQL_RELEASE>-postgresql	tdp-postgresql chart (pre-existing)	PostgreSQL admin password — read by the database creation Job
openmetadata-postgresql-secrets	tdp-openmetadata chart (hook weight -10)	openmetadata_user password — used by OpenMetadata Server
<RELEASE_NAME>-postgresql-secrets	tdp-openmetadata chart (hook weight -10)	Release-prefixed copy of the previous secret

Hook details

When externalServices.postgresql.enabled: true, the chart runs the following hooks before the server starts:

1. pre-install/pre-upgrade hook (weight -10) — creates two Secrets:

   • openmetadata-postgresql-secrets (used by OpenMetadata)
   • <RELEASE_NAME>-postgresql-secrets (release-prefixed copy)

2. pre-install/pre-upgrade hook (weight -5) — database creation Job:

   • connects to PostgreSQL using the admin password from the tdp-postgresql Secret
   • creates the openmetadata_db database and the openmetadata_user user
   • sets the user as the database owner

3. Regular resources — the OpenMetadata server starts and connects to PostgreSQL.

Prerequisites

• tdp-postgresql chart deployed in the same namespace (or an accessible namespace).
• PostgreSQL admin Secret automatically created by tdp-postgresql.

Quick start

Add the PostgreSQL configuration to your values file and apply via Helm:

externalServices:
  postgresql:
    enabled: true
    releaseName: "tdp-postgresql"

openmetadata-dependencies:
  mysql:
    enabled: false

tdp-openmetadata:
  openmetadata:
    config:
      database:
        enabled: true
        host: "tdp-postgresql"
        port: 5432
        driverClass: org.postgresql.Driver
        dbScheme: postgresql
        databaseName: openmetadata_db
        auth:
          username: openmetadata_user
          password:
            secretRef: "openmetadata-postgresql-secrets"
            secretKey: "openmetadata-postgresql-password"

Terminal input

helm upgrade --install <RELEASE_NAME> \
  oci://registry.tecnisys.com.br/tdp/charts/tdp-openmetadata \
  -n <NAMESPACE> --create-namespace \
  -f <VALUES_FILE> \
  --wait --wait-for-jobs --timeout 20m

Manual configuration

Use this option when you prefer full control over the parameters or do not want to rely on the provided overlay file. You need to explicitly configure three blocks: enable external PostgreSQL, disable internal MySQL and point OpenMetadata to the new database.

Configure the three blocks below in your values file:

# 1. Enable external PostgreSQL
externalServices:
  postgresql:
    enabled: true
    releaseName: "tdp-postgresql"  # name of the tdp-postgresql release
    namespace: ""                   # empty = same namespace as OpenMetadata
    database:
      secretName: "openmetadata-postgresql-secrets"  # auto-generated

# 2. Disable bundled MySQL
openmetadata-dependencies:
  mysql:
    enabled: false

# 3. Configure OpenMetadata for PostgreSQL
tdp-openmetadata:
  openmetadata:
    config:
      database:
        enabled: true
        host: "tdp-postgresql"
        port: 5432
        driverClass: org.postgresql.Driver
        dbScheme: postgresql
        databaseName: openmetadata_db
        auth:
          username: openmetadata_user
          password:
            secretRef: "openmetadata-postgresql-secrets"
            secretKey: "openmetadata-postgresql-password"

Cross-namespace deployment

If PostgreSQL is in a different namespace, use the service FQDN:

externalServices:
  postgresql:
    enabled: true
    releaseName: "tdp-postgresql"
    namespace: "postgresql-namespace"

tdp-openmetadata:
  openmetadata:
    config:
      database:
        host: "tdp-postgresql.postgresql-namespace.svc.cluster.local"

Verification

Terminal input

# Check the database creation job
kubectl -n <NAMESPACE> get jobs -l app.kubernetes.io/instance=<RELEASE_NAME>

# Verify the generated secret
kubectl -n <NAMESPACE> get secret openmetadata-postgresql-secrets -o yaml

# Confirm the database in PostgreSQL
kubectl exec -n <NAMESPACE> <POSTGRESQL_POD> -- psql -U postgres -c "\l openmetadata_db"

Example

Exemplo

kubectl exec -n <NAMESPACE> tdp-postgresql-0 -- psql -U postgres -c "\l openmetadata_db"

Troubleshooting

Symptom	Likely cause	Fix
Job fails with "secret not found"	PostgreSQL admin Secret missing	Confirm tdp-postgresql is deployed and its secret exists
Job fails with "connection refused"	Wrong service name or namespace	Check host and namespace in values
OpenMetadata cannot connect	User not created	Check db-create-job logs
"Secret already exists"	Manually created secret	Delete the manual secret and let the chart manage it

Migration from MySQL to PostgreSQL

1. Back up your data (MySQL data is not automatically migrated).
2. Uninstall the current release (keep PVCs if you want them for reference).
3. Reinstall with the PostgreSQL overlay (clean install with PostgreSQL).

Access & Security

External exposure

Ingress and Gateway API are mutually exclusive, controlled by TDP-Settings.gateway.*. In OpenMetadata, Ingress is configured under tdp-openmetadata.ingress.* and Gateway API under gatewayApi.openmetadata.* (port 8585).

For the complete values examples (Ingress and Gateway API), see External exposure.

Access

While Ingress is disabled or being configured, use the port-forward below to access the interface and API at the default service port.

Terminal input

kubectl port-forward svc/<RELEASE_NAME> 8585:8585 -n <NAMESPACE>

Access http://localhost:8585 in your browser. Default credentials are shown in the helm install output (NOTES):

• User: admin@open-metadata.org
• Password: admin (default; change in production via values)

Security

OpenMetadata supports two authentication modes:

• Basic (default): local user/password managed by OpenMetadata itself.
• LDAP: authentication delegated to a corporate directory (AD, OpenLDAP etc.).

In production, disable self-registration (enableSelfSignup: false) to control who can create accounts. Administrator and datasource job credentials must not be stored as plain text in values — use Kubernetes Secrets.

For detailed configuration — LDAP (DNs, attributes, roles, truststore), access control, Secrets and operational best practices — see Security — OpenMetadata.

Troubleshooting

Troubleshooting

Terminal input

kubectl -n <NAMESPACE> get jobs
kubectl -n <NAMESPACE> logs job/<RELEASE_NAME>-register-datasources

Common failures: OpenMetadata not yet ready, authentication error, missing Secret or unreachable target service. For detailed diagnostics, see Integrations — OpenMetadata.

Uninstallation

Uninstallation

Terminal input

helm uninstall <RELEASE_NAME> -n <NAMESPACE>

The chart includes a post-delete Job that automatically removes resources left by the release:

• PVCs: data-mysql-0, opensearch-opensearch-0 and other release volumes
• Secrets: mysql-secrets, airflow-secrets, om-secret-* (created by ingestion Jobs)
• ConfigMaps: mysql-init-scripts and related resources
• Jobs and CronJobs: om-job-*, om-cronjob-*, cron-deploy-pipelines, cron-reindex
• Completed Pods: om-job-*, om-automation-test-connection-*

To preserve PVCs or secrets for analysis, use --no-hooks (the cleanup Job will not run):

Terminal input

helm uninstall <RELEASE_NAME> -n <NAMESPACE> --no-hooks

Post-uninstall verification:

Terminal input

kubectl -n <NAMESPACE> get jobs,cronjobs,pods,secrets | \
  grep -E 'om-job-|om-cronjob-|om-secret-|cron-deploy-pipelines|cron-reindex|om-automation-test-connection' || true