diff options
| -rw-r--r-- | README.md | 3 |
1 files changed, 2 insertions, 1 deletions
@@ -55,7 +55,7 @@ Gitaly will make our situation better in a few steps: 1. One central place to monitor operations 1. Performance improvements doing less and caching more 1. Move the git operations from the app to the file/git server with git rpc (routing git access over JSON HTTP calls) -1. Use Git ketch to allow active-active (push to a local server), and distributed read operations (read from a secondary). +1. Use Git ketch to allow active-active (push to a local server), and distributed read operations (read from a secondary). This is far in the future, we might also use a distributed key value store instead. See the [active-active issue](https://gitlab.com/gitlab-org/gitlab-ee/issues/1381). Until we are active active we can just use persistent storage on the cloud to shard, this eliminates the need for redundancy. ## Decisions @@ -87,6 +87,7 @@ All design decision should be added here. 1. Use gitaly-client or HTTP/websocket clients? gitlab-shell copies the SSH stream, both ways, to gitaly over a websocket, workhorse just forwards the request to Gitaly, let’s use HTTP. https://gitlab.com/gitlab-org/gitaly/issues/5#note_20294280 1. We will use [E3 from BitBucket to measure performance closely in isolation](https://gitlab.com/gitlab-org/gitaly/issues/34). 1. Use environment variables for setting configurations (see #20). +1. GitLab already has [logic so that the application servers know which file/git server contains what repository](https://docs.gitlab.com/ee/administration/repository_storages.html), this eliminates the need for a router. ## Iterate |