Validate the accuracy of our migration docs and scripts
There has been a report from a user https://gitlab.zendesk.com/agent/tickets/104488 trying to migrate from an omnibus installation that is being used in production to the charts using the backup and restore
The user has been following https://gitlab.com/charts/gitlab/blob/master/doc/installation/migration/index.md#migration-steps.
The problems faced so far:
- The user was using google cloud storage instead of s3 and so had to disable the runner cache
- For some reason the backup tar ended up with empty uploads, artifacts, lfs
- Repositories restoration reported that it was successful however the repos where empty and gitaly showed logs indicating that the repositories are corrupted git repos. Re-running the restore seems to have fixed the gitaly side of things but when navigating into the project it still showed empty repo mainly because of the cache and so by clearing the cache we were able to see the repos populated again
- Result of running
gitlab-rake gitlab:check
reports several errors related to the absence of hooks, sidekiq being down .. etc . I didn't validate yet that this command works for cloud native charts in general perhaps there might be some gitaly routes that are not yet migrated (ill still have to verify that) - Importing projects failed with sidekiq showing errors of absent tables (the ones we usually see when we have a broken migration run). Re-running the migrations fixed that but I am still unaware of how things went to that point from the restore
info about the user installation
- Uses GCS
- Uses external postgres
Right now I am attempting to reproduce the state the user have in omnibus, create a backup from that and restore it to cloud native installation all by following the migration docs and take notes of findings in this issue.
Edited by 🤖 GitLab Bot 🤖