Can we enable object deduplication for gitlab-org/gitlab-ce?
Known problems:
-
no maintenance of dedup over time &524: not a reason not to turn it on -
forks of forks are not deduplicated #1532: not a reason not to turn it on -
What happens, or should happen, if a source project changes visibility, is deleted, or moves to another storage shard? #1488 (closed) -
What happens if SQL says the pool repo exists but Gitaly says it does not? #1533 (closed) -
What happens if SQL says a repository is not in a pool, but in Gitaly, it is? #1558 (closed) -
Ensure that Gitaly will not clobber existing, unexpected alternates links. #1534 (closed) -
at the time the Geo secondary tries to create the pool repository, the source project does not exist? #1533 (closed): we don't use geo in production at the moment (??)
Gitlab.com specific plan, so we can turn on the feature sooner for gitlab-org/gitlab-ce:
-
Put !1132 (merged) in a 11.9 patch release because it closes the door on our only data loss scenario -
For all other possible failures, use "turn off the feature flag" as a contingency -
To make the feature a two-way door, I will take some time to verify that moving a repository to another gitaly shard cleanly removes it from an object pool. This is not a general solution because it requires at least two Gitaly shards on your GitLab installation, and it requires GitLab EE. But that applies to gitlab.com so it would allow us to start exposing the feature to real use there. #1568 (closed)
Edited by Zeger-Jan van de Weg