Upgrade from Superset 5 to 6¶

This guide describes how to refresh a Superset deployment from track 5 to track 6, keeping everything stored in the metadata database: users, database connections, datasets, charts, and dashboards.

Besides the Superset major version, track 6 changes how the charm is configured. Credentials move into Juju secrets, and ingress, single sign-on, and the mail relay move from configuration options to relations. The table lists every option and endpoint of track 5 that track 6 no longer has:

Track 5	Track 6
`superset-secret-key`	`secret-key` in the Juju secret named by `signing-keys-secret-id`
`global-async-queries-jwt`	`async-queries-jwt` in the same secret
`admin-password`	Generated by the charm and read with the `get-admin-password` action
`external-hostname`, `tls-secret-name`, and the `nginx-route` endpoint	The `ingress` relation
`google-client-id`, `google-client-secret`, `oauth-domain`	The `oauth` relation
`smtp-secret-id`	The `smtp` relation, plus the `external-url` and `email-subject-prefix` options
`http-proxy`, `https-proxy`, `no-proxy`	The `juju-http-proxy`, `juju-https-proxy`, and `juju-no-proxy` model configuration
`charm-function=app`	`charm-function=app-gunicorn`

Before you refresh¶

Read the current secret key and keep the value:

juju config superset-k8s superset-secret-key

secret-key encrypts the database connection passwords stored in the metadata database. The new secret must carry this exact value, or every stored connection password becomes unreadable.

Remove GENERIC_CHART_AXES and HORIZONTAL_FILTER_BAR from feature-flags on every application if they are set. Superset 6 no longer has them, and the charm blocks on a flag it does not support.

If the UI is related to the Nginx Ingress Integrator over nginx-route, remove that relation. Track 6 has no such endpoint, and Juju refuses to refresh an application onto a charm that would break an existing relation:

juju remove-relation superset-k8s:nginx-route nginx-ingress-integrator

The UI stays unreachable through the ingress until you relate an ingress provider again after the refresh.

If the deployment set http-proxy, https-proxy, or no-proxy, set the same values as model configuration, which the charm passes on to the workload:

juju model-config juju-http-proxy=<HTTP_PROXY> juju-https-proxy=<HTTPS_PROXY> juju-no-proxy=<NO_PROXY>

Create the signing keys secret¶

Store the current secret key, together with a key for asynchronous queries, in a Juju user secret. Reuse the value of global-async-queries-jwt if you had set it, or generate a new one; nothing stored in the metadata database depends on it. Pass the keys in a file rather than on the command line, so that the secret key stays out of your shell history:

# signing-keys.yaml
secret-key: <CURRENT_SECRET_KEY>
async-queries-jwt: <NEW_RANDOM_VALUE>

juju add-secret superset-signing-keys --file=signing-keys.yaml

The command prints the secret ID. Delete the file once the secret exists, or store it somewhere protected. Grant the secret to every application of the deployment:

juju grant-secret superset-signing-keys superset-k8s,superset-k8s-worker,superset-k8s-beat

Refresh the applications¶

Refresh the UI application first, since it is the one that migrates the metadata database to the Superset 6 schema, and point it at the secret straight away:

juju refresh superset-k8s --channel 6/stable
juju config superset-k8s signing-keys-secret-id=<SECRET_ID>

Until the option is set, the unit reports blocked with missing required config: signing-keys-secret-id and does not start the workload, so the UI is down between the two commands.

Once the UI is active, refresh the worker and beat applications the same way, pointing them at the same secret:

juju refresh superset-k8s-worker --channel 6/stable
juju config superset-k8s-worker signing-keys-secret-id=<SECRET_ID>

juju refresh superset-k8s-beat --channel 6/stable
juju config superset-k8s-beat signing-keys-secret-id=<SECRET_ID>

The charm now generates the admin password and resets the admin account to it whenever the UI starts, so the password you set before stops working. Read the new one with:

juju run superset-k8s/leader get-admin-password

Reconnect ingress and single sign-on¶

Relate the UI to an ingress provider as described in Expose Superset with ingress. The hostname and TLS certificate are now the provider’s configuration, not Superset’s.

If the deployment used google-client-id and google-client-secret, follow Enable single sign-on. The existing Google client can be reused, but its authorized redirect URI must change from /oauth-authorized/google to /oauth-authorized/oidc. oauth-domain has no replacement: restrict who can sign in at the identity provider instead.

Move the SMTP settings¶

If the deployment set smtp-secret-id, deploy an SMTP integrator and relate it to all three applications as described in Enable alerts and reports. The keys of the old secret map onto the configuration of the integrator and two Superset options:

Old secret key	Track 6
`host`, `port`	`host`, `port` on `smtp-integrator`
`username`	`user` on `smtp-integrator`, with `auth_type=plain`
`password`	`password` in a Juju secret named by `password_secret` on `smtp-integrator`
`email`	`smtp_sender` on `smtp-integrator`
`starttls`, `ssl`	`transport_security=starttls` or `transport_security=tls` on `smtp-integrator`
`ssl-server-auth`	`skip_ssl_verify` on `smtp-integrator`, inverted
`superset-external-url`	`external-url` on the worker application
`email-subject-prefix`	`email-subject-prefix` on the worker application

Until the relation is in place, every application with ALERT_REPORTS in its feature-flags reports blocked with ALERT_REPORTS requires an smtp relation. Delete the old secret once the relation is in place.

Report screenshots are rendered by Playwright and Chromium in Superset 6, instead of Selenium and Firefox. Both are bundled in the workload image, so there is nothing to configure.

Verify¶

Each application reports active with the message Status check: UP:

juju status

Log in as admin with the new password and open a chart built on one of your database connections. A chart that loads its data confirms that the new secret carries the old key, since the connection password is decrypted with it.