Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • See what's new at GitLab
    • Help
    • Support
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
gitaly
gitaly
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 472
    • Issues 472
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 38
    • Merge Requests 38
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issues
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GitLab.org
  • gitalygitaly
  • Issues
  • #1533

Closed
Open
Opened Mar 07, 2019 by Jacob Vosmaer@jacobvosmaer-gitlab
  • Report abuse
  • New issue
Report abuse New issue

How does GitLab behave if a pool repository that should exist in Gitaly cannot be found?

This is one of the edge cases around Git object deduplication. We track pool repositories in the GitLab SQL database but it can happen that the SQL record for a pool got created but the repository did not get created on disk in Gitaly.

  1. How will GitLab behave in this scenario? Will the user notice? Can there be data loss?
  2. How will GitLab recover from this scenario?

A particular example of this is Geo, where we currently have this logic:

    def create_object_pool_on_secondary?
      return unless ::Gitlab::Geo.secondary?
      return unless project.object_pool_missing?
      return unless pool_repository.source_project_repository.exists?

      true
    end

I wonder if it would be better to initialize an empty pool if there is no source project, so that at least there is a pool. Otherwise we are stuck with this inconsistency between SQL ("there is a pool repository") and Gitaly ("no, there is no pool repository").

Edited Mar 08, 2019 by Jacob Vosmaer

Linked issues

  • Discussion
  • Designs

The one place for your designs

To enable design management, you'll need to meet the requirements. If you need help, reach out to our support team for assistance.

Assignee
Assign to
12.0
Milestone
12.0
Assign milestone
Time tracking
None
Due date
None
4
Labels
Deliverable devopscreate git object deduplication groupgitaly
Assign labels
  • View project labels
Reference: gitlab-org/gitaly#1533