Superset deploys with a postgres db on a pv inside k8s. We haven't been using it because when we were deploying T336586 was still a mystery as to why it was happening and what could be done about it. Now that we have some ability to deal with k8s disk pressure, perhaps we should move away from trove back into the k8s cluster itself. As doing so should allow for a single commit deploy.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T340623 enable on Async Queries via Celery on https://superset.wmcloud.org/ | |||
| Resolved | rook | T343526 Move superset DB back inside k8s | |||
| Resolved | rook | T343527 Process for replicating DBs between clusters | |||
| Resolved | rook | T342699 automate superset db backup | |||
| Resolved | rook | T342431 backup for superset database |
Event Timeline
Comment Actions
A direct migration might be less possible than hoped, we get a bunch of this kind of stuff when we don't modify the tables:
2023-08-18T17:08:13.438000Z WARNING Source column "public"."ab_user"."fail_login_count" is casted to type "bigint" which is not the same as "integer", the type of current target database column "public"."ab_user"."fail_login_count". 2023-08-18T17:08:13.439000Z WARNING Source column "public"."ab_user"."created_on" is casted to type "timestamptz" which is not the same as "timestamp without time zone", the type of current target database column "public"."ab_user"."created_on". 2023-08-18T17:08:13.439000Z WARNING Source column "public"."ab_user"."changed_on" is casted to type "timestamptz" which is not the same as "timestamp without time zone", the type of current target database column "public"."ab_user"."changed_on". 2023-08-18T17:08:13.440000Z WARNING Source column "public"."ab_user"."created_by_fk" is casted to type "bigint" which is not the same as "integer", the type of current target database column "public"."ab_user"."created_by_fk".
There aren't too many things saved, so this is probably largely irrelevant, still there are some options to get charts and the like transferred. We can probably either import them manually (Will lack ownership, as the users won't exist yet on the new cluster) Or can probably leave the old cluster running on a different domain and people can export/import themselves. Both of these are backup kinds of things, where announcing early will help encourage anyone to backup then restore their charts and dashboards before we cut over.