Fresh database migrations fail with: `relation "exercises_exercisebase" does not exist` about docker HOT 16 CLOSED

(closing here, if you run into other problems, just open a new issue)

from docker.

Hi! Are you using the docker compose on its own or with something like portainer? From what I have heard from some other users, it is possible that the db container takes too much time to start so that during the initial bootstrap the database isn't correctly initialised (even if it's marked that the application should wait for it). Dropping everything and manually starting the database container first and then the rest should do the trick (only during the first run, later it won't matter)

from docker.

I am using docker-compose, I've even manually started each part of the application.
I've also tried dropping, deleting volumes and restarting.

It's worth noting that changing to v2.1-dev does get further and migrations are applied, but I end up with:

  Applying nutrition.0010_logitem_meal... OK
  Applying nutrition.0011_alter_logitem_datetime... OK
  Applying sessions.0001_initial... OK
  Applying sites.0001_initial... OK
  Applying sites.0002_alter_domain_unique... OK
  Applying weight.0001_initial... OK
  Applying weight.0002_auto_20150604_2139... OK
  Applying weight.0003_auto_20160416_1030... OK
Set site URL to https://exercise.****.com
Using gunicorn...
[2023-07-12 12:16:18 +0000] [10] [INFO] Starting gunicorn 20.1.0
[2023-07-12 12:16:18 +0000] [10] [INFO] Listening at: http://0.0.0.0:8000 (10)
[2023-07-12 12:16:18 +0000] [10] [INFO] Using worker: sync
[2023-07-12 12:16:18 +0000] [11] [INFO] Booting worker with pid: 11
Internal Server Error: /en/software/features
Traceback (most recent call last):
  File "/home/wger/src/wger/utils/language.py", line 54, in load_language
    language = Language.objects.get(short_name=used_language)
  File "/usr/local/lib/python3.10/dist-packages/django/db/models/manager.py", line 85, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/django/db/models/query.py", line 435, in get
    raise self.model.DoesNotExist(
wger.core.models.language.Language.DoesNotExist: Language matching query does not exist.

Which I believe has been fixed by other users by deleting and manually firing each container up which I will give a go.

from docker.

let me try to spin up a fresh install, just in case

from docker.

It's almost instant, this is with wger/server:latest.

Also thanks for the quick responses, let me know if I can do anything else to help

from docker.

yeah, you're right, something is not right. But why? We didn't do anything(tm)

Will take a look

from docker.

I think I got something. It seems the celery service tried to sync the exercises before the application was ready (the time when this happens is randomly selected). Changing the order of the services fixed this for me (and in any case, this is more correct anyway)

celery_worker:
  depends_on:
    web:
      condition: service_healthy
celery_beat:
  depends_on:
    celery_worker:
      condition: service_healthy

however it looks like yours breaks down even before that, mhhh

from docker.

Will give that a go, though in my testing, I'm pretty sure I didn't even startup the celery_worker or celery_beat

Edit: Definitely getting the issue without any of the celery_* running

from docker.

Also can't get 2.1-dev running for some other completely different migration issues! But then I think the compose might not be valid for 2.1.

wger.core.models.language.Language.DoesNotExist: Language matching query does not exist.

I won't push this one as obviously it's old code that has potentially already been fixed.

from docker.

In the meantime - do you have any older digest ids of the :latest tag in docker that I could pull?
Happy to test out multiple previous digests to find the error-causing one if necessary. Assume they'll be in Github Actions?

from docker.

yeah, 2.1 is really old and I'm not sure if it would work with the current compose file. I also tried the current setup with a mac, linux and and arm server from hetzner without any problems so I'm not sure what could be happening. Are you using a somewhat new docker? And yes, all the info about the images are in github actions https://github.com/wger-project/wger/actions/workflows/docker.yml

from docker.

Ah right, so to clarify, you're not seeing the issue at all? Definitely my end?

from docker.

Exactly, everything works fine

from docker.

Ok no worries, I will plough on through! Thanks for taking the time. Will update this issue if I have time to fix it! :)

I'm actually using docker-compose version 2.4 so, fairly old as I'm slotting this into the rest of my docker-compose setup.
Super weird though as it definitely looks like an application/setup issue as opposed to a docker internal issue.

This is the very first error that occurs:

Traceback (most recent call last):
  File "/home/wger/.local/bin/wger", line 33, in <module>
    sys.exit(load_entry_point('wger', 'console_scripts', 'wger')())
  File "/home/wger/.local/bin/wger", line 22, in importlib_load_entry_point
    for entry_point in distribution(dist_name).entry_points
  File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 957, in distribution
    return Distribution.from_name(distribution_name)
  File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 548, in from_name
    raise PackageNotFoundError(name)
importlib.metadata.PackageNotFoundError: No package metadata was found for wger

from docker.

Ok as it turns out, it was my own fault due to being lazy with permissions, but it does kind of raise another question.

I had added user: 0:0 to the docker-compose for the database and wger_server, and removing that got it building again, so it didn't like that for whatever reason. This got the migrations running correctly etc.

However and unfortunately, I was now getting permission denied errors during the collectstatic step.

docker exec wger python3 manage.py collectstatic
------
PermissionError: [Errno 13] Permission denied: '/home/wger/static/django_extensions'

Given this config:

  wger:
    image: wger/server:latest
    container_name: wger
    depends_on:
      wger_db:
        condition: service_healthy
      wger_cache:
        condition: service_healthy
    env_file:
      - .env.wger
    volumes:
      - ${CONFIG_DIR}/wger/static:/home/wger/static
      - ${CONFIG_DIR}/wger/media:/home/wger/media
    healthcheck:
      test: wget --no-verbose --tries=1 --spider http://localhost:8000
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped  

A quick mkdir ${CONFIG_DIR}/wger/static && chmod 777 ${CONFIG_DIR}/wger/static (Obviously don't copy me here) does actually fix this error and get the collectstatic method running, but it does raise some notes for me:

1. The collectstatic step fails silently during docker-compose up
2. I don't know why it is getting permission denied errors, as not a single other container in my (Fairly large) setup, needs any permission modifications. Though I will fully admit that this is most likely due to my lack of knowledge.

One last note is that other containers I'm using (In particular the linuxserver images) allow setting PGID and PUID for this kind of control.

Thanks again for the hard work on this software and responding to my issue. Looking forward to pretending I exercise alot!

from docker.

alright, wasn't expecting this to be a permissions problem!

but yeah, the volumes are there for a reason 😇 Specially under windows regular mappings were a real pain and the volumes hide everything neatly away. One of these days I'll sit down and see which permissions are needed to use regular folders (in the end we don't do anything crazy with them, specially the static files are just a collection of js and css files that need to be writable by one container and readable by another) and document everything

Looking forward to pretending I exercise alot!

this is the way

from docker.