GitLab Geo: Git LFS support / synchronization with object storage
Background
Git LFS support was added in %9.0 by gitlab-org/gitlab-ee!1382 (see also gitlab-org/gitlab-ee!1530).
But since the implementation of gitlab-org/gitlab-ee!2760 in %10.0, LFS objects also can be stored on object storage (S3) (see also gitlab-org/gitlab-ee#2841).
Rationale
Now LFS support on S3 object storage is implemented, we should select an S3 compatible daemon that supports replication / multi copy (like Riak or Ceph), integrate it into our omnibus install, create documentation on how to setup replication and make some minimal changes to re-enable LFS read-only support on secondary Geo.
As temporary fix, LFS object on object storage are ignored, but a permanent solution to actually sync them should be provided.
Checklist
...
Activity
mentioned in issue #76
mentioned in issue #846
The original description was outdated:
GitLab Geo: Git LFS support / synchronization Rationale
GLFS support should not be handled the same way we do with other Git repositories in Geo (#76). Dealing with large files should be something an storage layer takes care.
There is an issue to implement S3 object storage support for LFS (gitlab-ce#13825 (closed)). This is an essential step to have LFS working for GitLab Geo.
The issue suggests we use minio, which should be fine for the CE version, but it is not enough for the EE if we want to enable Geo support, as minio does not support "multi copy / replication": https://github.com/minio/minio/issues/1159#issuecomment-187992086 LFS support / synchronization
We are currently blocked by gitlab-ce#13825 (closed).
After LFS have S3 object storage support implemented, we should select an S3 compatible daemon that supports replication / multi copy (like Riak or Ceph), integrate it into our omnibus install, create documentation on how to setup replication and make some minimal changes to re-enable LFS read-only support on secondary Geo.
mentioned in issue #3371 (closed)
added lfs label
changed milestone to %Next 2-3 months
