docker-compose non-dev superset-init fails to migrate database

[crucialfelix]

Following the documentation:

docker-compose -f docker-compose-non-dev.yml up

Expected results

it should initialize and startup.

Actual results

superset_init fails due to a missing table.

superset_init           | sqlalchemy.exc.ProgrammingError: (psycopg2.errors.UndefinedTable) relation "ab_permission_view_role" does not exist
superset_init           | LINE 2: FROM ab_role LEFT OUTER JOIN (ab_permission_view_role AS ab_...
superset_init           |                                       ^
superset_init           |
superset_init           | [SQL: SELECT ab_role.id AS ab_role_id, ab_role.name AS ab_role_name, ab_permission_view_1.id AS ab_permission_view_1_id, ab_permission_view_1.permission_id AS ab_permission_view_1_permission_id, ab_permission_view_1.view_menu_id AS ab_permission_view_1_view_menu_id
superset_init           | FROM ab_role LEFT OUTER JOIN (ab_permission_view_role AS ab_permission_view_role_1 JOIN ab_permission_view AS ab_permission_view_1 ON ab_permission_view_1.id = ab_permission_view_role_1.permission_view_id) ON ab_role.id = ab_permission_view_role_1.role_id]

How to reproduce the bug

docker-compose -f docker-compose-non-dev.yml up

Environment

• superset version: superset version

I tried both:

Today's master: d6f9c48

tag: v2021.31.0 which looks like it was the last release

Though I guess in both cases it is only using the docker-compose file. Its the image that it's loading that is not working.

I also tried changing the docker-compose to point at master-dev rather than latest-dev:

x-superset-image: &superset-image apache/superset:master-dev

and

x-superset-image: &superset-image apache/superset:latest

Checklist

Make sure to follow these steps before submitting your issue - thank you!

• I have checked the superset logs for python stacktraces and included it here as text if there are any.
• I have reproduced the issue with at least the latest released version of superset.
• I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context

Thanks, the project looks very interesting!

[vialcollet]

Same issue here... :(

[wengzhenjie]

I have a same problem.

[wengzhenjie]

I have a same problem.

I run this cmd docker-compose down -v . And then I run docker-compose -f docker-compose-non-dev.yml up -d. It works.

[crucialfelix]

I did get it to initialize by running:

docker-compose up superset-init

Let it finish initializing, then you can bring up the whole "cluster"

I think it can be fixed by changing the other services from:

depends_on: *superset-depends-on

to:

depends_on: superset-init

[clorichel]

Watch out, the depends_on sounds like an appealing idea, but won't do it here because: "for startup Compose does not wait until a container is “ready” (whatever that means for your particular application) - only until it’s running" as mentioned in the Docker documentation (https://docs.docker.com/compose/startup-order/).

So the other containers will actually start as soon as superset-init is started, not once it's done doing all the stuff it's made to do.

Also been hitting this issue, and similarly to #10711 be aware initializing can just fail from time to time for reasons I do not know. The timing of the containers might be the reason, and if that's the case some better coordination between superset-init and the other containers would then be needed (like a wait-for-init.sh such as the one described in the Docker docs) to actually fix the issue.

---

Simply said, until the real reasons are found and fixed, if you are facing this issue:

1. just CTRL+C then remove the containers and their volumes with the -v option :
   docker-compose -f docker-compose-non-dev.yml down -v

2. restart and enjoy:
   docker-compose -f docker-compose-non-dev.yml down

[rusackas]

Seeing as the last comments on this thread were from 2021, I'm going to hope all is well here and close out this thread. For what it's worth, I just tested docker-compose -f docker-compose-non-dev.yml up just yesterday on 1.5.2, 1.5.3, and 2.0.1, and they all worked just fine.