Integrations¶

Relation endpoints¶

Required¶

Endpoint	Interface	Description
`postgresql_db`	`postgresql_client`	Metadata database: users, roles, database connections, datasets, dashboards, and the action log. Provided by postgresql-k8s or postgresql.
`redis`	`redis`	Results cache and Celery message broker. Provided by redis-k8s.

Both endpoints accept a single relation, and the charm stays blocked until both exist. Every application of a deployment - UI, worker, and beat - integrates with the same PostgreSQL and Redis applications.

Optional¶

Endpoint	Interface	Description
`ingress`	`ingress`	Exposes the web server (port 8088) through an ingress provider such as traefik-k8s or nginx-ingress-integrator, with TLS terminated at the ingress. The provider reports the external URL back to the charm, which uses it as the OIDC callback host. Superset serves at the root path, so the provider must be configured to serve it at a root URL. Relate the UI application only.
`oauth`	`oauth`	Single sign-on through an OIDC identity provider, from any charm that provides the `oauth` interface, such as oauth-external-idp-integrator. The charm registers itself as a client and reads the provider details back. It needs the external URL an `ingress` provider reports, so with an `oauth` relation and no HTTPS ingress URL the charm blocks with `OAuth requires an HTTPS ingress URL`. See Enable single sign-on.
`certificates`	`tls-certificates`	Installs a CA certificate into the workload trust store, so Superset can reach services presenting certificates from a private CA. See Trust a certificate authority.
`trino-catalog`	`trino_catalog`	Database connections created automatically from trino-k8s catalogs, with per-relation credentials.
`smtp`	`smtp`	The outgoing mail relay used to deliver alerts and reports, from smtp-integrator. Required whenever the `ALERT_REPORTS` feature flag is set, unless `report-dry-run` is also set: with the flag and no relation the charm blocks with `ALERT_REPORTS requires an smtp relation`. See Enable alerts and reports.
`logging`	`loki_push_api`	Forwards workload logs to Loki.

Provided¶

Endpoint	Interface	Description
`metrics-endpoint`	`prometheus_scrape`	Prometheus scrape configuration for the StatsD exporter on port 9102 (UI and worker) and the Celery exporter on port 9103 (worker). A beat application publishes no scrape job. See Observability.
`grafana-dashboard`	`grafana_dashboard`	Ships the “Superset Metrics” dashboard to Grafana.

Charm-managed resources in Superset¶

Through the Trino integration, the charm creates resources inside Superset itself:

Resource	Naming pattern	Example
Database connection	`<Catalog title-cased> (<catalog>)`	`Google Ads (google_ads)`
Permission grant	`database_access` on the connection, granted to the role named by `self-registration-role`	`database_access` granted to `Public`

The charm only creates connections and updates their URI when the Trino host, port, username, or credentials change. It never renames or deletes a connection, and never touches connections created by administrators. See Integrate with Trino.

Juju secrets used by the charm¶

Secret	Owner	Purpose
Signing keys (user-supplied, any name)	User	`secret-key` and `async-queries-jwt`; referenced by the `signing-keys-secret-id` configuration option and granted to each application. Required.
Admin user password	Superset charm	The admin account password, generated by the leader on first start. Read it with the `get-admin-password` action.
SMTP relay password	SMTP integrator charm	The relay password, granted to Superset over the `smtp` relation. The integrator publishes only the secret ID, never the password itself, and rotation is picked up automatically.
Trino relation credentials	Trino charm	Per-relation Trino username and password, granted to Superset over the `trino-catalog` relation. Rotation is picked up automatically.

The signing keys are user-supplied because they outlive any one application: secret-key encrypts the database connection passwords stored in the metadata database, so a deployment rebuilt against a surviving database must be given the same key or those passwords cannot be read. The UI, worker, and beat applications of one deployment must all name the same secret, and it must be granted to each of them. Keep the secret backed up independently of the model.

The admin password is the opposite case: the charm generates it, so nothing has to be supplied at deploy time and no password is passed on a command line. It is stored in an application-owned secret, and the get-admin-password action returns it.