staging-next-version/deposit: Failure to trigger migration

I'll have a look later.

I've looked a bit and i think the trouble lies it's trying to connect with the swh user. But the deposit db may have been created from a dump with a role swh-deposit. Hence the mismatch there.

After fixing the mess (grant connect, reassign owner...), everything looks fine. Some more work is need at the chart level to fix this.

swh-deposit=# grant connect on database "swh-deposit" to swh;
GRANT
swh-deposit=# reassign owned by "swh-deposit" to swh;
REASSIGN OWNED

Then:

2024-12-04T15:44:57.049396219Z Operations to perform:
2024-12-04T15:44:57.049475757Z   Apply all migrations: auth, contenttypes, deposit, sessions
2024-12-04T15:44:57.049492774Z Running migrations:
2024-12-04T15:44:57.069986233Z   Applying auth.0012_alter_user_first_name_max_length... OK
2024-12-04T15:44:57.110651512Z   Applying deposit.0024_deposit_software_version_and_release_notes... OK
2024-12-04T15:45:15.891488414Z   Applying deposit.0025_set_release_data... OK

(edited, i the wrong log from the other pod which had nothing to do because the other did it ^)

That's not the proper fix. As mentioned earlier, the swh-deposit role is coming from the original db. The next-version dbs are mounted from the original staging dbs and thus keep their original roles. I'm currently tracking and fixing properly the connection of the deposit db to use swh-deposit. So that, at next reset [1], everything is still wired properly.

[1] soon, #5515 (closed)

Next step will be to unstuck the bootstrap of this db (to avoid the swh/swh-deposit role clash definitively). Or else, at the next reset of the backends in next-version, this will come back. (later)

mentioned in merge request swh/infra/ci-cd/swh-charts!516 (merged)

mentioned in commit swh/infra/ci-cd/swh-charts@f015e580

mentioned in commit swh/infra/ci-cd/swh-charts@8c7099d1

mentioned in issue #5513

mentioned in commit swh/infra/ci-cd/swh-charts@d693f6f8

I've resetted the permissions and grant to the user/role swh-deposit for the db swh-deposit in next-version. And i've fixed the credentials used by the deployment accessing the deposit db [1]

So everything is back in order now [2] At the next reset, everything should go smoothly and not disrupt any migration set to happen.

Tested in next-version with [3]

[3] swh/infra/ci-cd/swh-charts!522 (merged)

[1]

postgres@next-version-dbs-1:/$ psql swh-deposit
psql (16.2 (Debian 16.2-1.pgdg110+2))
Type "help" for help.

swh-deposit=# \conninfo
You are connected to database "swh-deposit" as user "postgres" via socket in "/controller/run" at port "5432".
...
grant connect on database "swh-deposit" to "swh-deposit";
reassign owned by "swh-deposit" to "swh-deposit";
grant all privileges on all tables in schema public to "swh-deposit";
grant all privileges on all sequences in schema public to "swh-deposit";

[2]

2024-12-13T09:52:29.403418340Z Operations to perform:
2024-12-13T09:52:29.403476523Z   Apply all migrations: auth, contenttypes, deposit, sessions
2024-12-13T09:52:29.403485889Z Running migrations:
2024-12-13T09:52:29.403492819Z   No migrations to apply.
2024-12-13T09:56:30.010887123Z Stream closed EOF for swh-cassandra-next-version/deposit-845c58cb9b-4dv6g (do-migration)

closed

mentioned in commit swh/infra/ci-cd/swh-charts@fe914681

staging-next-version/deposit: Failure to trigger migration

Designs

Child items ...

Activity