Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gitaly gitaly
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 547
    • Issues 547
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 54
    • Merge requests 54
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • gitalygitaly
  • Issues
  • #3209
Closed
Open
Created Oct 15, 2020 by Derek Ferguson@derekfergusonDeveloper

Automatically select shard to move repository to based on existing weights

A user should be able to issue a repository move API request where, instead of providing the target shard, you tell GitLab to automatically select it using the randomized weighs. This way, the exact same algorithm that we use for picking the shard for a new repo could be used for migrating repositories off a hotspot node.

The current API requires the destination_storage_name parameter.

The updated API would make destination_storage_name optional. If it was not specified, as random node would be selected.

POST /projects/:project_id/repository_storage_moves?project_id=....

Since the hotspot nodes would have weight zero, the relocation would never move the nodes to another hotspot.

This would guarantee that whatever logic the application uses (and continues to evolve) for repository selection can be used automatically for migration.

Of course, we would still have the option to move repositories using a specific shard, if we wished.

This would greatly reduce the amount of duplicate logic.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking