Geo secondaries do not handle uploads changing location when a project is renamed
Summary
As noted in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3066#note_42640542
On the primary, two filesystem operations are run in response to a project path being renamed that are not replicated on the secondary: https://gitlab.com/gitlab-org/gitlab-ee/blob/v10.0.0-ee/app/models/project.rb#L1356
- Uploads are not renamed
- Pages files are not renamed
Steps to reproduce
- Create a project on hashed or legacy storage, upload an avatar, run a Pages job
- Wait for it to be replicated to the secondary
- Rename the project
What is the current bug behavior?
The files are stored on disk under project.full_path
. The primary will rename the files, but the secondary will not.
What is the expected correct behavior?
The files should be renamed. Alternatively, with hashed storage enabled, the files should be stored under disk_path
rather than full_path
. Preferably both.
Possible fixes
These are "hashed storage leftovers" - however, since these circumstances were never handled on the Geo secondary with legacy storage either, they do not represent a regression relative to that baseline.
/cc @brodock @dbalexandre
Tasks
-
Enable Hashed Storage for Attachments (gitlab-org/gitlab-ce!15068) -
Remove existing files from disk from old file location (gitlab-org/gitlab-ee!3259) -
Mark FileRegistry for resync on new file location (gitlab-org/gitlab-ee!3259) -
Implement migration path for Attachments to move to Hashed Storage (gitlab-org/gitlab-ce!15352) -
Implement Geo specific code for replicating Attachments migration to secondaries (gitlab-org/gitlab-ee!3544)