diff options
Diffstat (limited to 'doc/development/geo')
| -rw-r--r-- | doc/development/geo/framework.md | 8 | ||||
| -rw-r--r-- | doc/development/geo/proxying.md | 16 |
2 files changed, 16 insertions, 8 deletions
diff --git a/doc/development/geo/framework.md b/doc/development/geo/framework.md index 3624d280f86..60529db5ce6 100644 --- a/doc/development/geo/framework.md +++ b/doc/development/geo/framework.md @@ -18,6 +18,14 @@ across Geo sites. This API is presented as a Ruby Domain-Specific Language (DSL) and aims to make it possible to replicate data with minimal effort of the engineer who created a data type. +## Geo is a requirement in the definition of done + +Geo is the GitLab solution for [disaster recovery](https://about.gitlab.com/direction/geo/disaster_recovery/). A robust disaster recovery solution must replicate **all GitLab data** such that all GitLab services can be successfully restored in their entirety with minimal data loss in the event of a disaster. + +For this reason, Geo replication and verification support for GitLab generated data is part of the [definition of done](../contributing/merge_request_workflow.md#definition-of-done). This ensures that new features ship with Geo support and our customers are not exposed to data loss. + +Adding Geo support with the Self Service Framework (SSF) is easy and outlined in detail on this page for various types of data. However, for a more general guide that can help you decide if and how you need to add Geo support for a new GitLab feature, [you may start here](../geo.md#ensuring-a-new-feature-has-geo-support). + ## Nomenclature Before digging into the API, developers need to know some Geo-specific diff --git a/doc/development/geo/proxying.md b/doc/development/geo/proxying.md index 67d4129a9d0..f3136890788 100644 --- a/doc/development/geo/proxying.md +++ b/doc/development/geo/proxying.md @@ -260,12 +260,7 @@ S-->>C: return Git response from primary ## Git push -### Unified URLs - -With unified URLs, a push will redirect to a local path formatted as `/-/push_from_secondary/$SECONDARY_ID/*`. Further -requests through this path will be proxied to the primary, which will handle the push. - -#### Git push over SSH +### Git push over SSH As SSH operations go through GitLab Shell instead of Workhorse, they are not proxied through the mechanism used for Workhorse requests. With SSH operations, they are proxied as Git HTTP requests to the primary site by the secondary @@ -293,7 +288,12 @@ I-->>S: <response> S-->>C: return Git response from primary ``` -#### Git push over HTTP(s) +### Git push over HTTP(S) + +#### Git push over HTTP(S) unified URLs + +With unified URLs, a push redirects to a local path formatted as `/-/push_from_secondary/$SECONDARY_ID/*`. Further +requests through this path are proxied to the primary, which will handle the push. ```mermaid sequenceDiagram @@ -326,7 +326,7 @@ W-->>Wsec: Pipe messages to the Git client Wsec-->>C: Return piped messages from Git ``` -### Git push over HTTP with Separate URLs +#### Git push over HTTP(S) with separate URLs With separate URLs, the secondary will redirect to a URL formatted like `$PRIMARY/-/push_from_secondary/$SECONDARY_ID/*`. |