wger-project / docker

Production...ish docker-compose image for wger
GNU Affero General Public License v3.0
137 stars 46 forks source link

Celery Worker - no such table: exercises_exercisebase #104

Closed ctag closed 3 weeks ago

ctag commented 4 weeks ago

Hi,

When starting the production compose file, I am encountering the following error in the celery worker container:

...
  File "/home/wger/.local/lib/python3.12/site-packages/celery/fixups/django.py", line 100, in on_import_modules
    self.worker_fixup.validate_models()
  File "/home/wger/.local/lib/python3.12/site-packages/celery/fixups/django.py", line 140, in validate_models
    run_checks()
  File "/home/wger/.local/lib/python3.12/site-packages/django/core/checks/registry.py", line 88, in run_checks
    new_errors = check(app_configs=app_configs, databases=databases)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/wger/.local/lib/python3.12/site-packages/django/core/checks/model_checks.py", line 36, in check_all_models
    errors.extend(model.check(**kwargs))
                  ^^^^^^^^^^^^^^^^^^^^^
  File "/home/wger/src/wger/exercises/models/base.py", line 148, in check
    no_translations = cls.no_translations.all().count()
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/wger/.local/lib/python3.12/site-packages/django/db/models/query.py", line 608, in count
    return self.query.get_count(using=self.db)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/wger/.local/lib/python3.12/site-packages/django/db/models/sql/query.py", line 568, in get_count
    return obj.get_aggregation(using, {"__count": Count("*")})["__count"]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/wger/.local/lib/python3.12/site-packages/django/db/models/sql/query.py", line 554, in get_aggregation
    result = compiler.execute_sql(SINGLE)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/wger/.local/lib/python3.12/site-packages/django/db/models/sql/compiler.py", line 1562, in execute_sql
    cursor.execute(sql, params)
  File "/home/wger/.local/lib/python3.12/site-packages/django/db/backends/utils.py", line 67, in execute
    return self._execute_with_wrappers(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/wger/.local/lib/python3.12/site-packages/django/db/backends/utils.py", line 80, in _execute_with_wrappers
    return executor(sql, params, many, context)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/wger/.local/lib/python3.12/site-packages/django/db/backends/utils.py", line 84, in _execute
    with self.db.wrap_database_errors:
  File "/home/wger/.local/lib/python3.12/site-packages/django/db/utils.py", line 91, in __exit__
    raise dj_exc_value.with_traceback(traceback) from exc_value
  File "/home/wger/.local/lib/python3.12/site-packages/django/db/backends/utils.py", line 89, in _execute
    return self.cursor.execute(sql, params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/wger/.local/lib/python3.12/site-packages/django/db/backends/sqlite3/base.py", line 328, in execute
    return super().execute(query, params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
django.db.utils.OperationalError: no such table: exercises_exercisebase

This feels similar to https://github.com/wger-project/docker/issues/63 but I haven't changed the permissions, and am not sure how to proceed with troubleshooting. So far I have tried deleting the volumes and re-starting, as well as starting 'db' first, letting it finish init, and then starting the other containers.

full logs: logs.txt

Shelling into db and checking the tables:

wger=# \l
                                             List of databases   Name    | Owner | Encoding |  Collate   |   Ctype    | ICU Locale | Locale Provider | Access privileges 
-----------+-------+----------+------------+------------+------------+-----------------+-------------------
 postgres  | wger  | UTF8     | en_US.utf8 | en_US.utf8 |            | libc            | 
 template0 | wger  | UTF8     | en_US.utf8 | en_US.utf8 |            | libc            | =c/wger          +
           |       |          |            |            |            |                 | wger=CTc/wger
 template1 | wger  | UTF8     | en_US.utf8 | en_US.utf8 |            | libc            | =c/wger          +
           |       |          |            |            |            |                 | wger=CTc/wger
 wger      | wger  | UTF8     | en_US.utf8 | en_US.utf8 |            | libc            | (4 rows)wger=# \c wger
You are now connected to database "wger" as user "wger".wger=# \dt
Did not find any relations.
rolandgeider commented 3 weeks ago

hi!


web-1            |   Applying sites.0001_initial... OK
web-1            |   Applying sites.0002_alter_domain_unique... OK
web-1            |   Applying weight.0001_initial... OK
web-1            |   Applying weight.0002_auto_20150604_2139... OK
web-1            |   Applying weight.0003_auto_20160416_1030... OK
web-1            | Installed 1 object(s) from 1 fixture(s)
web-1            | Installed 24 object(s) from 1 fixture(s)
web-1            | Installed 6 object(s) from 1 fixture(s)
web-1            | Installed 3 object(s) from 1 fixture(s)
web-1            | Installed 5 object(s) from 1 fixture(s)
web-1            | Installed 7 object(s) from 1 fixture(s)
web-1            | Installed 7 object(s) from 1 fixture(s)
web-1            | Installed 6 object(s) from 1 fixture(s)

while that looks alright to me and it seems the database is being correctly migrated and the initial data imported, I don't really like the errors coming from File "/home/wger/.local/lib/python3.12/site-packages/django/db/backends/sqlite3/base.py and not the postgres backend. Did you change something in the config?

ctag commented 3 weeks ago

Thank you for taking a look at this.

I did shoehorn the project into my existing caddy setup, but I don't believe any of those changes should break things (or, at least, only break static files). Files attached, I will rotate the passwords and reset but wanted them left alone in case it's a length/match issue.

I thought I had it figured out last night. In the flurry of replacing passwords with generated ones POSTGRES_PASSWORD and DJANGO_DB_PASSWORD were set to different values, but I saw DJANGO_DB_HOST and realized DJANGO is probably a db client so it needs the same password. Set them to match, took all the containers down, deleted the volumes, brought it back up and still no dice. The wger database is empty and the "no such table" entries are still made.

Compose file: compose.txt Env: env.txt

rolandgeider commented 3 weeks ago

aha, I think I got it! It seems you removed the env_file: - ./config/prod.env from the compose file. While there are sensible defaults if the env variables are not set, if DJANGO_DB_ENGINE is not set, we default to using a local sqlite db

https://github.com/wger-project/wger/blob/master/extras/docker/production/settings.py#L21

(If you are setting the env variables somewhere else, they should be picked up, though, you don't need to pass them like that)

ctag commented 3 weeks ago

Sorry, I forgot that part. I moved prod.env to be ./.env so that it would be configurable through dockge. The containers should still receive the environment variables automatically, I think.

Image

Edit. I'm wrong with that screenshot. Those environment variables are coming from environment: in the compose file. I was sure .env was the default file name for that.

Edit 2. OK, I see where I went wrong: https://stackoverflow.com/a/72368718. I learned something new today! Going to put that env_file back now.

ctag commented 3 weeks ago

Moving .env back to ./config/prod.mod.env and setting that as the env_file value worked! Up and running now. Rolandgeider, thank you!

rolandgeider commented 3 weeks ago

🙌🏻 🙌🏻 🙌🏻

glad you got it working!