diff options
Diffstat (limited to 'doc/architecture/blueprints/object_storage/index.md')
-rw-r--r-- | doc/architecture/blueprints/object_storage/index.md | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/doc/architecture/blueprints/object_storage/index.md b/doc/architecture/blueprints/object_storage/index.md index b70339c8b8d..7a4ecd0e5a8 100644 --- a/doc/architecture/blueprints/object_storage/index.md +++ b/doc/architecture/blueprints/object_storage/index.md @@ -31,8 +31,8 @@ underlying implementation for shared, distributed, highly-available (HA) file storage. Over time, we have built support for object storage across the -application, solving specific problems in a -[multitude of iterations](https://about.gitlab.com/company/team/structure/working-groups/object-storage/#company-efforts-on-uploads). +application, solving specific problems in a +[multitude of iterations](https://about.gitlab.com/company/team/structure/working-groups/object-storage/#company-efforts-on-uploads). This has led to increased complexity across the board, from development (new features and bug fixes) to installation: @@ -67,7 +67,7 @@ This has led to increased complexity across the board, from development The following is a brief description of the main directions we can take to remove the pain points affecting our object storage implementation. -This is also available as [a YouTube video](https://youtu.be/X9V_w8hsM8E) recorded for the +This is also available as [a YouTube video](https://youtu.be/X9V_w8hsM8E) recorded for the [Object Storage Working Group](https://about.gitlab.com/company/team/structure/working-groups/object-storage/). ### Simplify GitLab architecture by shipping MinIO @@ -78,7 +78,7 @@ local storage and object storage. With local storage, there is the assumption of a shared storage between components. This can be achieved by having a single box -installation, without HA, or with a NFS, which +installation, without HA, or with a NFS, which [we no longer recommend](../../../administration/nfs.md). We have a testing gap on object storage. It also requires Workhorse @@ -134,7 +134,7 @@ access to new features without infrastructure chores. Our implementation is built on top of a 3rd-party framework where every object storage client is a 3rd-party library. Unfortunately some -of them are unmaintained. +of them are unmaintained. [We have customers who cannot push 5GB Git LFS objects](https://gitlab.com/gitlab-org/gitlab/-/issues/216442), but with such a vital feature implemented in 3rd-party libraries we are slowed down in fixing it, and we also rely on external maintainers @@ -214,7 +214,7 @@ Proposal: DRIs: -The DRI for this blueprint is the +The DRI for this blueprint is the [Object Storage Working Group](https://about.gitlab.com/company/team/structure/working-groups/object-storage/). <!-- vale gitlab.Spelling = YES --> |