Add geo hashed storage warning

doc/gitlab-geo/README.md

 # GitLab Geo
 
->**Note:**
-GitLab Geo is in **Beta** development. It is considered experimental and
-not production-ready. It will undergo significant changes over the next year,
-and there is significant chance of data loss. For the latest updates, check the
-[meta issue](https://gitlab.com/gitlab-org/gitlab-ee/issues/846).
-
 > **Notes:**
 - GitLab Geo is part of [GitLab Enterprise Edition Premium][ee].
 - Introduced in GitLab Enterprise Edition 8.9.
@@ -14,6 +8,7 @@ and there is significant chance of data loss. For the latest updates, check the
 - You should make sure that all nodes run the same GitLab version.
 - GitLab Geo requires PostgreSQL 9.6 and Git 2.9 in addition to GitLab's usual
   [minimum requirements](../install/requirements.md)
+- Using GitLab Geo in combination with High Availability is considered **Beta**
 
 >**Note:**
 GitLab Geo changes significantly from release to release. Upgrades **are**

doc/gitlab-geo/configuration.md

@@ -89,16 +89,24 @@ running and accessible.
 
 ### Step 2. Enabling hashed storage (from GitLab 10.0)
 
+>**Warning**
+Hashed storage is in **Beta**. It is considered experimental and not
+production-ready. For the latest updates, check 
+[issue](https://gitlab.com/gitlab-com/infrastructure/issues/2821).
+Hashed Storage is not required to run GitLab Geo, but in some edge cases race
+conditions can lead to errors and Geo to break. Known issues are renaming a
+project multiple times in short succession, deleting a project and recreating
+with the same name very quickly.
+
+Using hashed storage significantly improves Geo replication - project and group
+renames no longer require synchronization between nodes.
+
 1. Visit the **primary** node's **Admin Area ➔ Settings**
    (`/admin/application_settings`) in your browser
 1. In the `Repository Storages` section, check `Create new projects using hashed storage paths`:
 
     ![](img/hashed-storage.png)
 
-Using hashed storage significantly improves Geo replication - project and group
-renames no longer require synchronization between nodes - so we recommend it is
-used for all GitLab Geo installations.
-
 ### Step 3. (Optional) Configuring the secondary to trust the primary
 
 You can safely skip this step if your primary uses a CA-issued HTTPS certificate.

doc/gitlab-geo/configuration_source.md

@@ -93,16 +93,29 @@ immediately. Make sure the secondary instance is running and accessible.
 
 ### Step 2. Enabling hashed storage (from GitLab 10.0)
 
+>**Note:**
+Hashed storage is in **Beta**. It is considered experimental and not
+production-ready. For the latest updates, check 
+[issue](https://gitlab.com/gitlab-com/infrastructure/issues/2821).
+Hashed Storage is not required to run GitLab Geo, but in some edge cases race
+conditions can lead to errors and Geo to break. Known issues are renaming a
+project multiple times in short succession, deleting a project and recreating
+with the same name very quickly.
+
+>**Note:**
+Instances already using hashed storage are not recommended to disable hashed
+storage, since bugs affecting hashed storage would continue to affect these
+projects.
+
+Using hashed storage significantly improves Geo replication - project and group
+renames no longer require synchronization between nodes.
+
 1. Visit the **primary** node's **Admin Area ➔ Settings**
    (`/admin/application_settings`) in your browser
 1. In the `Repository Storages` section, check `Create new projects using hashed storage paths`:
 
     ![](img/hashed-storage.png)
 
-Using hashed storage significantly improves Geo replication - project and group
-renames no longer require synchronization between nodes - so we recommend it is
-used for all GitLab Geo installations.
-
 ### Step 3. (Optional) Configuring the secondary to trust the primary
 
 You can safely skip this step if your primary uses a CA-issued HTTPS certificate.