Nach Umzug meiner gitlab-omnibus-Installation auf einen anderen Server habe ich auch die Migration von legacy zu hashed storage durchgeführt.

Leider hat das bei 39 von knapp 150 Projekten bzw. deren Repos nicht funktioniert. Auch mehrmaliges Anstoßen führte zu keiner Fehlermeldung. Ab Gitlab Version 14.x gibt es den legacy storage nicht mehr ... man muss hier also tätig werden.

Relevante Links dazu: https://docs.gitlab.com/ee/administration/raketasks/storage.html  https://docs.gitlab.com/ee/administration/repository_storage_paths.htmlhttps://forum.gitlab.com/t/repo-migration-fails-projects-repositoryinuseerror/48808   https://forum.gitlab.com/t/a-number-of-hashed-storage-project-migrate-jobs-failed-projects-show-the-repository-for-this-project-does-not-exist/46002/6 (mit Script zum Rücksetzen des readonly flag)

Der grundlegende Hinweis war, man soll nicht auf 13.4.0, sondern gleich auf 13.5.4 updaten - was aber, wenn man zwischendurch auf der fehlerhaften Version war?

Scheinbar passiert Folgendes: repos werden im hashed storage neu angelegt, können aber wegen readonly-flag nicht im legacy storage gelöscht werden.

Wenn man o.g. Script nutzt, sind die readonly flags zwar weg - aber die migration funktioniert trotzdem nicht, weil das Repo im legacy wie auch im hashed storage vorhanden ist.

Hilfen dazu:

gitlab-rake gitlab:storage:list_legacy_projects | tee legacy_projects.txt
find /var/opt/gitlab/git-data/repositories/@hashed/ -name config -exec grep -H "fullpath" {} \; | tee list-hashed-repos.txt
grep -H fullpath /var/opt/gitlab/git-data/repositories/*/*.git/config  | tee list-legacy-repos.txt
# in einem anderen terminal zur Kontrolle:
tail -n100 -f /var/log/gitlab/sidekiq/current |grep moved
# pro repo und ID aus legacy_projects.txt führe aus:
# grep -h (reponame) list*txt
# lösche repo im hashed storage, dann:
gitlab-rake gitlab:storage:rollback_to_legacy ID_FROM=129 ID_TO=129 && gitlab-rake gitlab:storage:legacy_projects

Hier hilft also nur, eine Liste der Projekte mit legacy storage UND hashed storage zu erstellen. Der  jeweils überflüssige Pfad im hashed storage wird gelöscht WENN dasselbe Repo im legacy storage vorhanden ist und dann wird die Migration erneut angestoßen, erfolgreich.

Das lässt sich zwar auch sicherlich per Script automatisieren, wenn es zu viele Repos sind ... aber in dem Fall war mir wichtiger, dass nicht aus Versehen etwas Falsches gelöscht wird.

Leider bleiben ein paar Repos übrig, die kein legacy Repo mehr haben - nur ein hashed - die aber immer noch als "legacy" aufgeführt werden .... wenn jemand weiß, was zu tun ist: gern Mail-an-mich