Overview
A typical request: an analytics team runs Apache Superset for internal dashboards on a release that is several versions old, with local user accounts and permissions edited by hand. It wants to upgrade and to sign users in through the company identity provider. AceMQ works with Superset specialists to plan and rehearse the upgrade, set up SSO and write the access model down. It is a scope-and-process engagement, not a dashboard build.
Challenge
A Superset upgrade changes the metadata database, where chart and dashboard definitions, users and logs live. The project's UPDATING.md lists backward-incompatible changes release by release, and its upgrade guide advises a backup, a staging test and an off-peak window. Meanwhile the supporting services matter: workers and the web server need the same Celery configuration, only one beat may run, and the results cache has to be cleared. Access is its own risk, because role mapping, the registration role and the Public role are easy to leave at defaults that surprise people after an upgrade.
Environment
Self-hosted Apache Superset on Kubernetes or virtual machines with a PostgreSQL metadata database, Redis for cache and broker, Celery workers and beat, and a data warehouse as the main data source.
Approach
AceMQ reads the installation read-only, then builds a plan from the release notes and UPDATING.md for the versions between the current release and the target. It rehearses the upgrade on a copy of the metadata database and the configuration, including superset db upgrade and superset init, and decides the backup point and the way back. In parallel it designs sign-in through the identity provider using Flask AppBuilder's OAuth settings, with roles mapped from groups and row-level filters reviewed.
Solution
- Inventory of version, install method, configuration, feature flags and the metadata database size and backup history
- Breaking-change list for each release between the current version and the target, read against the customer's configuration
- Upgrade rehearsal on a copy of the metadata database, with the order of steps, the backup point and rollback written down
- Cache and results-backend clearing, workers drained and one beat confirmed before the cut-over
- SSO through the identity provider with role mapping and the registration role set deliberately, and a SECRET_KEY rotation procedure
- Review of row-level security filters and Public role handling so they hold after superset init
Outcome
The customer receives a written upgrade plan with a rehearsal record, a configuration for SSO and roles that its own engineers can maintain, a rollback procedure and a handover pack. The upgrade is carried out by the customer's engineers with AceMQ in the room, or run by AceMQ if the customer prefers, and the decision to go ahead rests on tested evidence.
Technologies
PostgreSQL
Redis
Prometheus
Linux
Amazon S3
Terraform
RabbitMQ
