Closed ericxliu1990 closed 1 year ago
When database is created a db stamp
command should be called to stamp database version for migrations to know from where to where migrate... that should be handled by gitlab-tools post_install --config_prod --user=gitlab-tools
command...
And for periodic sync to work, you need to have celery_beat
service running
@cenk1cenk2 maybe docker issue?^
Thanks Slamek for the quick response. Is the issue due to inappropriate DB init in docker? If so, should I move this issue to https://github.com/cenk1cenk2/docker-gitlab-tools?
As the log suggested, celerybeat service was running. I also can confirm celerybeat and celeryworker running in the same docker container.
(venv) root@gitlab-tools-649f54b688-44llp:/opt/gitlab-tools# ps aux | grep [c]elery
service 3439 0.0 1.0 115660 85224 ? S 13:39 0:00 python manage.py celerybeat --config_prod --schedule=/home/service/celery_beat.db --pid=/tmp/celerybeat.pid
service 3443 0.0 1.0 116312 86460 ? S 13:39 0:01 python manage.py celeryworker --config_prod
service 3459 0.0 0.9 115380 75940 ? S 13:39 0:00 python manage.py celeryworker --config_prod
@ericxliu1990 well looks like that migration crash is issue in docker version since i could not find any code running db stamp
after database init and that migration crash can be related to scheduled tasks not working (IDK) we need to get those migrations working first and applied correctly....
Hey, I run the migrations on any start-up but I guess it would only be applied correctly if the database is fresh, I did not do any stamping for the migrations version, I thought something like that should be used at the end of the migration.
Where the database initiation and initial migrations happen is in this https://github.com/cenk1cenk2/docker-gitlab-tools/blob/main/hostfs/etc/cont-init.d/10-migrate-database.sh script. What should we change about it to make it proper?
@cenk1cenk2 after db create_all
there should be db stamp
(?db stamp head
?) command as in https://github.com/Salamek/gitlab-tools/blob/d48892e53309a2d8ddf798f1fb79db1cf9ae0a4e/gitlab_tools/bin/gitlab_tools.py#L288
That marks DB with current last migration UUID so next migration can know from where to start migrating from...
@ericxliu1990 as for you, you need to insert correct UUIDs intoalembic_version
table to match your previous version installation, after that db migration should work ok. You can check existing uuids in git by filtering by your previous version tag and looking into gitlab_tools/migrations dir
Thanks for the heads up @Salamek, sorry for missing that.
Now the migrations are not failing after the stamping procedure. The thing is that I left the bash script as is so it is still too okay for migrations to fail. So existing users can upgrade and it will stamp it for them and after that, it will stop failing.
But yeah, anybody can pull the newer version now and give it a try, if it also solves the problem of cron jobs.
@ericxliu1990 i have looked into migrations folder and all migrations are ~4y old, so to fix your migration crash, just call
python manage.py db stamp head
After this crash is solved, we can move to the periodic tasks not working...
There were some incorrect imports in scheduler implementation, should be fixed in https://github.com/Salamek/gitlab-tools/commit/ccf0fc8ffc209a5fc32535d085ec9e2d1e3af4d8
I can manually trigger the sync using the web UI or webhook. But the period sync never triggered. Did I missed something trivial?
Periodic sync: Every minute (/1 *)