Skip to content
Snippets Groups Projects

Handle repository creations, deletions and renames atomically

Merged Handle repository creations, deletions and renames atomically
smh-repository-id-rename-repository into master
Merged Sami Hiltunen requested to merge smh-repository-id-rename-repository into master

Renaming, creating and deleting repositories is racy in Praefect. They can also partially fail in awkward ways due to Praefect first applying the operations on the disks of the Gitalys and later updating its metadata store. In order to make these operations atomic, there's been ongoing work in the background to make it possible to perform these in the database in a manner that races are not possible and partial failures do not end up conflicting with future operations.

Renames can be fixed by doing the rename atomically in the database without moving any repositories on the disks.

Deletes can be modeled as simply deleting the repository's database record.

Creates are atomic by creating the repository's database record as the last step in the process.

The last piece of the puzzle is to ensure repositories always land in different directories on the disk. This ensures that a partial failure doesn't block a future operation from succeeding. This commit implements that piece by deriving a unique path for each repository to store their replicas. Existing repositories stay where they are but newly created repositories will land in unique directories.

Create might succeed on a disk but fail to be persisted in the database. Prior to this change, attempting to recreate a repository might fail due to the stale state on the disk. With this in place, the next attempt at creating the repository would still succeed as the new attempt would land the repository in a different directory on the disk.

Deletes have the same problem prior to this commit. The repository's metadata may be successfully deleted but if we fail to delete the repository from the disk, future creations and renames may fail if they conflict with the stale state. As creates now always land in a different directory, the stale state no longer causes problems.

Renames will work purely in the database, so any stale state on the disk will not affect them.

Closes #3485 (closed)
Closes #4003 (closed)

Edited by Sami Hiltunen

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
Please register or sign in to reply