Merge branch 'sh-geo-upgrading-consolidation-doc' into 'master'

Consolidate Geo upgrade instructions into one document

Closes #3628

See merge request gitlab-org/gitlab-ee!3057

doc/gitlab-geo/configuration.md

@@ -312,41 +312,7 @@ not create them manually.
 
 ### Upgrading Geo
 
-#### Upgrading to GitLab 10.1
-
-[Hashed storage](../administration/repository_storage_types.md) was introduced
-in GitLab 10.0, and a [migration path](../administration/raketasks/storage.md)
-for existing repositories was added in GitLab 10.1.
-
-After upgrading to GitLab 10.1, we recommend that you
-[enable hashed storage for all new projects](#step-5-enabling-hashed-storage-from-gitlab-100),
-then [migrate existing projects to hashed storage](../administration/raketasks/storage.md).
-This will significantly reduce the amount of synchronization required between
-nodes in the event of project or group renames.
-
-#### Upgrading to GitLab 10.0
-
-Since GitLab 10.0, we require all **Geo** systems to [use SSH key lookups via
-the database](ssh.md) to avoid having to maintain consistency of the
-`authorized_keys` file for SSH access. Failing to do this will prevent users
-from being able to clone via SSH.
-
-#### Upgrading from GitLab 9.3 or older
-
-If you started running Geo on GitLab 9.3 or older, we recommend that you
-resync your secondary PostgreSQL databases to use replication slots. If you
-started using Geo with GitLab 9.4 or 10.x, no further action should be
-required because replication slots are used by default. However, if you
-started with GitLab 9.3 and upgraded later, you should still follow the
-instructions below.
-
-When in doubt, it does not hurt to do a resync. The easiest way to do this in
-Omnibus is the following:
-
-  1. Install GitLab on the primary server
-  1. Run `gitlab-ctl reconfigure` and `gitlab-ctl restart postgresql`. This will enable replication slots on the primary database.
-  1. Install GitLab on the secondary server.
-  1. Re-run the [database replication process](database.md#step-3-initiate-the-replication-process).
+See the [updating the Geo nodes document](updating_the_geo_nodes.md).
 
 ## Troubleshooting
 

doc/gitlab-geo/updating_the_geo_nodes.md

@@ -14,6 +14,42 @@ all you need to do is update GitLab itself:
    the tracking database is enabled.
 1. [Test](#check-status-after-updating) primary and secondary nodes, and check version in each.
 
+## Upgrading to GitLab 10.1
+
+[Hashed storage](../administration/repository_storage_types.md) was introduced
+in GitLab 10.0, and a [migration path](../administration/raketasks/storage.md)
+for existing repositories was added in GitLab 10.1.
+
+After upgrading to GitLab 10.1, we recommend that you
+[enable hashed storage for all new projects](#step-5-enabling-hashed-storage-from-gitlab-100),
+then [migrate existing projects to hashed storage](../administration/raketasks/storage.md).
+This will significantly reduce the amount of synchronization required between
+nodes in the event of project or group renames.
+
+## Upgrading to GitLab 10.0
+
+Since GitLab 10.0, we require all **Geo** systems to [use SSH key lookups via
+the database](ssh.md) to avoid having to maintain consistency of the
+`authorized_keys` file for SSH access. Failing to do this will prevent users
+from being able to clone via SSH.
+
+## Upgrading from GitLab 9.3 or older
+
+If you started running Geo on GitLab 9.3 or older, we recommend that you
+resync your secondary PostgreSQL databases to use replication slots. If you
+started using Geo with GitLab 9.4 or 10.x, no further action should be
+required because replication slots are used by default. However, if you
+started with GitLab 9.3 and upgraded later, you should still follow the
+instructions below.
+
+When in doubt, it does not hurt to do a resync. The easiest way to do this in
+Omnibus is the following:
+
+  1. Install GitLab on the primary server
+  1. Run `gitlab-ctl reconfigure` and `gitlab-ctl restart postgresql`. This will enable replication slots on the primary database.
+  1. Install GitLab on the secondary server.
+  1. Re-run the [database replication process](database.md#step-3-initiate-the-replication-process).
+
 ## Special update notes for 9.0.x
 
 > **IMPORTANT**: