Accessing the Service

Superset - http://127.0.0.1:8089/

Using the superset_config.py file

The Superset package is configured to contain a superset_config.py file, which Superset looks for, and subsequently activates the contained feature flags. For more information on the allowed feature flags, visit https://github.com/apache/superset/blob/master/RESOURCES/FEATURE_FLAGS.md.

Importing & Exporting Assets

The config importer written in JS will import the file superset-export.zip that exists in the folder <path to project packages>/dashboard-visualiser-superset/importer/config. The assets that will be imported to Superset are the following:

• The link to the Clickhouse database

• The dataset saved from Clickhouse DB

• The dashboards

• The charts

If you made any changes to these objects please don't forget to export and save the file as superset-export.zip under the folder specified above. NB! It is not possible to export all these objects from the Superset UI, you can check the Postman collection: CARES DISI CDR -> Superset export assets and you will find two requests. To do the export, three steps are required:

1. Run the Get Token Superset request to get the token (please make sure that you are using the correct request URL). An example of a response from Superset that will be displayed: { "access_token": "eyJ0eXAiOiJKV1...." }

2. Copy the access token and put it into the second request Export superset assets in the Authorization section.

3. Run the second request Export superset assets . You can save the response into a file called superset-export.zip under the folder specified above.

Your changes should then be saved.

Version upgrade process (with rollback capability)

By default if you simply update the image that the superset service uses to a later version, when the container is scheduled it will automatically run a database migration and the version of superset will be upgraded. The problem, however, is that if there is an issue with this newer version you cannot rollback the upgrade since the database migration that ran will cause the older version to throw an error and the container will no longer start. As such it is recommended to first create a postgres dump of the superset postgres database before attempting to upgrade superset's version.

1. Exec into the postgres container as the root user (otherwise you will get write permission issues)

1. Run the pg_dump command on the superset database. The database name is stored in SUPERSET_POSTGRESQL_DATABASE and defaults to superset

1. Copy that dumpped sql script outside the container

1. Update the superset version (either through a platform deploy or with a docker command on the server directly -- docker service update superset_dashboard-visualiser-superset --image apache/superset:tag)

Rolling back upgrade

In the event that something goes wrong you'll need to rollback the database changes too, i.e.: run the superset_backup.sql script we created before upgrading the superset version

1. Copy the superset_backup.sql script into the container

1. Exec into the postgres container

1. Run the sql script (where -d superset is the database name stored in SUPERSET_POSTGRESQL_DATABASE)