Update Gitaly docs now NFS isn't required anymore

1 files changed, 17 insertions, 14 deletions

diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md
index 0795d3dad40..2d4b5c65c46 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -45,9 +45,13 @@ installations that are larger than a single machine. Most
 installations will be better served with the default configuration
 used by Omnibus and the GitLab source installation guide.
 
-Starting with GitLab 11.4, Gitaly is a replacement for NFS except
-when the [Elastic Search indexer](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer)
-is used.
+Starting with GitLab 11.4, Gitaly is able to serve all Git requests without
+needed a shared NFS mount for Git repository data.
+Between 11.4 and 11.8 the exception was the
+[Elastic Search indexer](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer).
+But since 11.8 the indexer uses Gitaly for data access as well. NFS can still
+be leveraged for redudancy on block level of the Git data. But only has to
+be mounted on the Gitaly server.
 
 ### Network architecture
 
@@ -62,14 +66,16 @@ is used.
 -   Gitaly addresses must be specified in such a way that they resolve
     correctly for ALL Gitaly clients
 -   Gitaly clients are: unicorn, sidekiq, gitlab-workhorse,
-    gitlab-shell, and Gitaly itself
+    gitlab-shell, Elasticsearch Indexer, and Gitaly itself
 -   special case: a Gitaly server must be able to make RPC calls **to
     itself** via its own (Gitaly address, Gitaly token) pair as
     specified in `gitlab-rails/config/gitlab.yml`
 -   Gitaly servers must not be exposed to the public internet
 
-Gitaly network traffic is unencrypted so you should use a firewall to
-restrict access to your Gitaly server.
+Gitaly network traffic is unencrypted by default, but supports
+[TLS](#tls-support). Authentication is done through a static token. For 
+security in depth, its recommended to use a firewall to restrict access 
+to your Gitaly server.
 
 Below we describe how to configure a Gitaly server at address
 `gitaly.internal:8075` with secret token `abc123secret`. We assume
@@ -194,17 +200,16 @@ server from reaching the Gitaly server then all Gitaly requests will
 fail.
 
 We assume that your Gitaly server can be reached at
-`gitaly.internal:8075` from your GitLab server, and that your GitLab
-NFS shares are mounted at `/mnt/gitlab/default` and
-`/mnt/gitlab/storage1` respectively.
+`gitaly.internal:8075` from your GitLab server, and that Gitaly can read and
+write to `/mnt/gitlab/default` and `/mnt/gitlab/storage1` respectively.
 
 Omnibus installations:
 
 ```ruby
 # /etc/gitlab/gitlab.rb
 git_data_dirs({
-  'default' => { 'path' => '/mnt/gitlab/default', 'gitaly_address' => 'tcp://gitaly.internal:8075' },
-  'storage1' => { 'path' => '/mnt/gitlab/storage1', 'gitaly_address' => 'tcp://gitaly.internal:8075' },
+  'default' => { 'gitaly_address' => 'tcp://gitaly.internal:8075' },
+  'storage1' => { 'gitaly_address' => 'tcp://gitaly.internal:8075' },
 })
 
 gitlab_rails['gitaly_token'] = 'abc123secret'
@@ -218,10 +223,8 @@ gitlab:
   repositories:
     storages:
       default:
-        path: /mnt/gitlab/default/repositories
         gitaly_address: tcp://gitaly.internal:8075
       storage1:
-        path: /mnt/gitlab/storage1/repositories
         gitaly_address: tcp://gitaly.internal:8075
 
   gitaly:
@@ -236,7 +239,7 @@ repository from your GitLab server over HTTP.
 
 ## TLS support
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22602) in GitLab 11.7.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22602) in GitLab 11.8.
 
 Gitaly supports TLS credentials for GRPC authentication. To be able to communicate
 with a Gitaly instance that listens for secure connections you will need to use `tls://` url