Update links

doc/administration/geo/replication/configuration.md

@@ -10,7 +10,7 @@ from source**](configuration_source.md) guide.
 >**Note:**
 This is the final step in setting up a secondary Geo node. Stages of the
 setup process must be completed in the documented order.
-Before attempting the steps in this stage, [complete all prior stages](README.md#using-omnibus-gitlab).
+Before attempting the steps in this stage, [complete all prior stages](index.md#using-omnibus-gitlab).
 
 The basic steps of configuring a secondary node are to replicate required
 configurations between the primary and the secondaries; to configure a tracking
@@ -90,7 +90,7 @@ with the same credentials as used in the primary.
 GitLab integrates with the system-installed SSH daemon, designating a user
 (typically named git) through which all access requests are handled.
 
-In a [Disaster Recovery](../disaster_recovery/index.md) situation, GitLab system
+In a [Disaster Recovery](../../disaster_recovery/index.md) situation, GitLab system
 administrators will promote a secondary Geo replica to a primary and they can
 update the DNS records for the primary domain to point to the secondary to prevent
 the need to update all references to the primary domain to the secondary domain,
@@ -144,7 +144,7 @@ keys must be manually replicated to the secondary node.
 
 >**Warning**
 Hashed storage is in **Beta**. It is not considered production-ready. See
-[Hashed Storage](../repository_storage_types.md) for more detail,
+[Hashed Storage](../../repository_storage_types.md) for more detail,
 and for the latest updates, check
 [infrastructure issue #2821](https://gitlab.com/gitlab-com/infrastructure/issues/2821).
 
@@ -155,7 +155,7 @@ renames no longer require synchronization between nodes.
    (`/admin/application_settings`) in your browser
 1. In the `Repository Storages` section, check `Create new projects using hashed storage paths`:
 
-    ![](img/hashed-storage.png)
+    ![](img/hashed_storage.png)
 
 ### Step 4. (Optional) Configuring the secondary to trust the primary
 
@@ -187,7 +187,7 @@ The initial replication, or 'backfill', will probably still be in progress. You
 can monitor the synchronization process on each geo node from the primary
 node's Geo Nodes dashboard in your browser.
 
-![Geo dashboard](img/geo-node-dashboard.png)
+![Geo dashboard](img/geo_node_dashboard.png)
 
 If your installation isn't working properly, check the
 [troubleshooting document](troubleshooting.md).

doc/administration/geo/replication/configuration_source.md

@@ -10,7 +10,7 @@ using the Omnibus GitLab packages, follow the
 >**Note:**
 This is the final step in setting up a secondary Geo node. Stages of the setup
 process must be completed in the documented order. Before attempting the steps
-in this stage, [complete all prior stages](README.md#using-gitlab-installed-from-source).
+in this stage, [complete all prior stages](index.md#using-gitlab-installed-from-source).
 
 The basic steps of configuring a secondary node are to replicate required
 configurations between the primary and the secondaries; to configure a tracking

doc/administration/geo/replication/database.md

@@ -273,7 +273,7 @@ because we have not yet configured the secondary server. This is the next step.
     sudo -i
     ```
 
-1. [Check TCP connectivity](../raketasks/maintenance.md) to the
+1. [Check TCP connectivity](../../raketasks/maintenance.md) to the
    primary's PostgreSQL server:
 
     ```bash
@@ -490,4 +490,4 @@ Read the [troubleshooting document](troubleshooting.md).
 [external postgresql]: #external-postgresql-instances
 [tracking]: database_source.md#enable-tracking-database-on-the-secondary-server
 [FDW]: https://www.postgresql.org/docs/9.6/static/postgres-fdw.html
-[toc]: README.md#using-omnibus-gitlab
+[toc]: index.md#using-omnibus-gitlab

doc/administration/geo/replication/database_source.md

@@ -392,4 +392,4 @@ Read the [troubleshooting document](troubleshooting.md).
 [pgback]: http://www.postgresql.org/docs/9.6/static/app-pgbasebackup.html
 [replication user]:https://wiki.postgresql.org/wiki/Streaming_Replication
 [FDW]: https://www.postgresql.org/docs/9.6/static/postgres-fdw.html
-[toc]: README.md#using-gitlab-installed-from-source
+[toc]: index.md#using-gitlab-installed-from-source

doc/administration/geo/replication/docker_registry.md

@@ -6,7 +6,7 @@ secondary Geo node that mirrors the one on the primary Geo node.
 ## Storage support
 
 CAUTION: **Warning:**
-If you use [local storage](../container_registry.md#container-registry-storage-driver)
+If you use [local storage](../../container_registry.md#container-registry-storage-driver)
 for the Container Registry you **cannot** replicate it to the secondary Geo node.
 
 Docker Registry currently supports a few types of storages. If you choose a
@@ -15,6 +15,6 @@ Registry on a primary Geo node, you can use the same storage for a secondary
 Docker Registry as well. For more information, read the
 [Load balancing considerations](https://docs.docker.com/registry/deploying/#load-balancing-considerations)
 when deploying the Registry, and how to setup the storage driver for GitLab's
-integrated [Container Registry](../container_registry.md#container-registry-storage-driver).
+integrated [Container Registry](../../container_registry.md#container-registry-storage-driver).
 
 [ee]: https://about.gitlab.com/products/

doc/administration/geo/replication/faq.md

@@ -5,7 +5,7 @@
 Yes, but there are limitations to what we replicate (see
 [What data is replicated to a secondary node?](#what-data-is-replicated-to-a-secondary-node)).
 
-Read the documentation for [Disaster Recovery](../disaster_recovery/index.md).
+Read the documentation for [Disaster Recovery](../../disaster_recovery/index.md).
 
 ## What data is replicated to a secondary node?
 

doc/administration/geo/replication/high_availability.md

@@ -6,7 +6,7 @@ described, it is possible to adapt these instructions to your needs.
 
 ## Architecture overview
 
-![Geo HA Diagram](../img/high_availability/geo-ha-diagram.png)
+![Geo HA Diagram](../../img/high_availability/geo-ha-diagram.png)
 
 _[diagram source - gitlab employees only](https://docs.google.com/drawings/d/1z0VlizKiLNXVVVaERFwgsIOuEgjcUqDTWPdQYsE7Z4c/edit)_
 
@@ -33,8 +33,8 @@ The two services will instead be configured such that
 they will each run on a single machine.
 
 For more information about setting up a highly available PostgreSQL cluster and Redis cluster using the omnibus package see the high availability documentation for
-[PostgreSQL](../high_availability/database.md) and
-[Redis](../high_availability/redis.md), respectively.
+[PostgreSQL](../../high_availability/database.md) and
+[Redis](../../high_availability/redis.md), respectively.
 
 From these instructions you will need the following for the examples below:
 * `gitlab_rails['db_password']` for the PostgreSQL "DB password"
@@ -53,18 +53,18 @@ Make sure you have GitLab EE installed using the
 
 On the **primary** backend servers configure the following services:
 
-* [Redis](../high_availability/redis.md) for high availability.
-* [NFS Server](../high_availability/nfs.md) for repository, LFS, and upload storage.
-* [PostgreSQL](../high_availability/database.md) for high availability.
+* [Redis](../../high_availability/redis.md) for high availability.
+* [NFS Server](../../high_availability/nfs.md) for repository, LFS, and upload storage.
+* [PostgreSQL](../../high_availability/database.md) for high availability.
 
 On the **secondary** backend servers configure the following services:
 
-* [Redis](../high_availability/redis.md) for high availability.
-* [NFS Server](../high_availability/nfs.md) which will store data that is synchronized from the Geo primary.
+* [Redis](../../high_availability/redis.md) for high availability.
+* [NFS Server](../../high_availability/nfs.md) which will store data that is synchronized from the Geo primary.
 
 ### Step 2: Configure the Postgres services on the Geo Secondary
 
-1. Configure the [secondary Geo PostgreSQL database](../gitlab-geo/database.md)
+1. Configure the [secondary Geo PostgreSQL database](database.md)
  as a read-only secondary of the primary Geo PostgreSQL database.
 
 1. Configure the Geo tracking database on the secondary server, to do this modify `/etc/gitlab/gitlab.rb`:
@@ -91,7 +91,7 @@ After making these changes be sure to run `sudo gitlab-ctl reconfigure` so that
 In this topology there will need to be a load balancers at each geographical location
 to route traffic to the application servers.
 
-See the [Load Balancer for GitLab HA](../high_availability/load_balancer.md)
+See the [Load Balancer for GitLab HA](../../high_availability/load_balancer.md)
 documentation for more information.
 
 ### Step 4: Configure the Geo Frontend Application Servers
@@ -192,5 +192,5 @@ On the secondary the following GitLab frontend services will be enabled:
 Verify these services by running `sudo gitlab-ctl status` on the frontend
 application servers.
 
-[reconfigure GitLab]: ../restart_gitlab.md#omnibus-gitlab-reconfigure
-[restart GitLab]: ../restart_gitlab.md#omnibus-gitlab-restart
+[reconfigure GitLab]: ../../restart_gitlab.md#omnibus-gitlab-reconfigure
+[restart GitLab]: ../../restart_gitlab.md#omnibus-gitlab-restart

doc/administration/geo/replication/index.md

@@ -7,7 +7,7 @@
   basic Geo features, or latest version for a better experience.
 - You should make sure that all nodes run the same GitLab version.
 - Geo requires PostgreSQL 9.6 and Git 2.9 in addition to GitLab's usual
-  [minimum requirements](../install/requirements.md)
+  [minimum requirements](../../../install/requirements.md)
 - Using Geo in combination with High Availability is considered **GA** in GitLab Enterprise Edition 10.4
 
 >**Note:**
@@ -31,7 +31,7 @@ Your Geo instance can be used for cloning and fetching projects, in addition to
 reading any data. This will make working with large repositories over large
 distances much faster.
 
-![Geo overview](img/geo-overview.png)
+![Geo overview](img/geo_overview.png)
 
 When Geo is enabled, we refer to your original instance as a **primary** node
 and the replicated read-only ones as **secondaries**.
@@ -52,14 +52,14 @@ improving speed for distributed teams
 - Helps reducing the loading time for automated tasks,
 custom integrations and internal workflows
 - Quickly fail-over to a Geo secondary in a
-[Disaster Recovery](../disaster_recovery/index.md) scenario
-- Allows [planned fail-over](../disaster_recovery/planned_fail_over.md) to a Geo secondary
+[Disaster Recovery](../../disaster_recovery/index.md) scenario
+- Allows [planned fail-over](../../disaster_recovery/planned_fail_over.md) to a Geo secondary
 
 ## Architecture
 
 The following diagram illustrates the underlying architecture of Geo:
 
-![Geo architecture](img/geo-architecture.png)
+![Geo architecture](img/geo_architecture.png)
 
 [Source diagram](https://docs.google.com/drawings/d/1Abw0P_H0Ew1-2Lj_xPDRWP87clGIke-1fil7_KQqrtE/edit)
 
@@ -89,7 +89,7 @@ current version of OpenSSH:
 
 Note that CentOS 6 and 7.0 ship with an old version of OpenSSH that do not
 support a feature that Geo requires. See the [documentation on Geo SSH
-access](../operations/fast_ssh_key_lookup.md) for more details.
+access](../../operations/fast_ssh_key_lookup.md) for more details.
 
 ### LDAP
 
@@ -144,14 +144,14 @@ If you installed GitLab using the Omnibus packages (highly recommended):
 1. [Install GitLab Enterprise Edition][install-ee] on the server that will serve
    as the **secondary** Geo node. Do not create an account or login to the new
    secondary node.
-1. [Upload the GitLab License](../user/admin_area/license.md) on the **primary**
+1. [Upload the GitLab License](../../../user/admin_area/license.md) on the **primary**
    Geo node to unlock Geo.
 1. [Setup the database replication](database.md) (`primary (read-write) <->
    secondary (read-only)` topology).
-1. [Configure fast lookup of authorized SSH keys in the database](../operations/fast_ssh_key_lookup.md),
+1. [Configure fast lookup of authorized SSH keys in the database](../../operations/fast_ssh_key_lookup.md),
    this step is required and needs to be done on both the primary AND secondary nodes.
 1. [Configure GitLab](configuration.md) to set the primary and secondary nodes.
-1. Optional: [Configure a secondary LDAP server](../auth/ldap.md)
+1. Optional: [Configure a secondary LDAP server](../../auth/ldap.md)
    for the secondary. See [notes on LDAP](#ldap).
 1. [Follow the "Using a Geo Server" guide](using_a_geo_server.md).
 
@@ -164,11 +164,11 @@ If you installed GitLab from source:
 1. [Install GitLab Enterprise Edition][install-ee-source] on the server that
    will serve as the **secondary** Geo node. Do not create an account or login
    to the new secondary node.
-1. [Upload the GitLab License](../user/admin_area/license.md) on the **primary**
+1. [Upload the GitLab License](../../../user/admin_area/license.md) on the **primary**
    Geo node to unlock Geo.
 1. [Setup the database replication](database_source.md) (`primary (read-write)
    <-> secondary (read-only)` topology).
-1. [Configure fast lookup of authorized SSH keys in the database](../operations/fast_ssh_key_lookup.md),
+1. [Configure fast lookup of authorized SSH keys in the database](../../operations/fast_ssh_key_lookup.md),
    do this step for both primary AND secondary nodes.
 1. [Configure GitLab](configuration_source.md) to set the primary and secondary
    nodes.
@@ -186,7 +186,7 @@ Read how to [update your Geo nodes to the latest GitLab version](updating_the_ge
 
 ## Configuring Geo HA
 
-Read through the [Geo High Availability documentation](ha.md).
+Read through the [Geo High Availability documentation](high_availability.md).
 
 ## Configuring Geo with Object storage
 
@@ -226,7 +226,7 @@ This message shows that Geo detected that a repository update was needed for pro
 
 ## Security of Geo
 
-Read the [security review](security-review.md) page.
+Read the [security review](security_review.md) page.
 
 ## Tuning Geo
 

doc/administration/geo/replication/object_storage.md

@@ -13,10 +13,10 @@ they can use a replicated storage bucket. At this time GitLab does not
 take care of content replication in object storage.
 
 For LFS, follow the documentation to
-[set up LFS object storage](../workflow/lfs/lfs_administration.md#setting-up-s3-compatible-object-storage).
+[set up LFS object storage](../../../workflow/lfs/lfs_administration.md#setting-up-s3-compatible-object-storage).
 
 For CI job artifacts, there is similar documentation to configure
-[jobs artifact object storage](../job_artifacts.md#using-object-storage)
+[jobs artifact object storage](../../job_artifacts.md#using-object-storage)
 
 Complete these steps on all nodes, primary **and** secondary.
 

doc/administration/geo/replication/troubleshooting.md

@@ -21,7 +21,7 @@ to help identify if something is wrong:
 - Is the node's secondary tracking database connected?
 - Is the node's secondary tracking database up-to-date?
 
-![Geo health check](img/geo-node-healthcheck.png)
+![Geo health check](img/geo_node_healthcheck.png)
 
 There is also an option to check the status of the secondary node by running a special rake task:
 

doc/administration/geo/replication/tuning.md

@@ -13,5 +13,5 @@ but this may not lead to a more downloads in parallel unless the number of
 available Sidekiq threads is also increased. For example, if repository sync
 capacity is increased from 25 to 50, you may also want to increase the number
 of Sidekiq threads from 25 to 50. See the [Sidekiq concurrency
-documentation](../operations/extra_sidekiq_processes.html#concurrency)
+documentation](../../operations/extra_sidekiq_processes.html#concurrency)
 for more details.

doc/administration/geo/replication/updating_the_geo_nodes.md

@@ -99,7 +99,7 @@ secondary if ever promoted to a primary:
 >**Warning**
 Hashed storage is in **Alpha**. It is considered experimental and not
 production-ready. See [Hashed
-Storage](../repository_storage_types.md) for more detail.
+Storage](../../repository_storage_types.md) for more detail.
 
 If you previously enabled Hashed Storage and migrated all your existing
 projects to Hashed Storage, disabling hashed storage will not migrate projects
@@ -111,16 +111,16 @@ migrated we recommend leaving Hashed Storage enabled.
 >**Warning**
 Hashed storage is in **Alpha**. It is considered experimental and not
 production-ready. See [Hashed
-Storage](../repository_storage_types.md) for more detail.
+Storage](../../repository_storage_types.md) for more detail.
 
-[Hashed storage](../repository_storage_types.md) was introduced
-in GitLab 10.0, and a [migration path](../raketasks/storage.md)
+[Hashed storage](../../repository_storage_types.md) was introduced
+in GitLab 10.0, and a [migration path](../../raketasks/storage.md)
 for existing repositories was added in GitLab 10.1.
 
 ## Upgrading to GitLab 10.0
 
 Since GitLab 10.0, we require all **Geo** systems to [use SSH key lookups via
-the database](../operations/fast_ssh_key_lookup.md) to avoid having to maintain consistency of the
+the database](../../operations/fast_ssh_key_lookup.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.
 
@@ -314,4 +314,4 @@ and it is required since 10.0.
 
 1. Repeat this step for every secondary node
 
-[update]: ../update/README.md
+[update]: ../../../update/README.md

doc/administration/geo/replication/using_a_geo_server.md

@@ -20,4 +20,4 @@ there are a few things to consider:
          git remote set-url --push origin git@primary.gitlab.example.com:user/repo.git
          ```
 
-[req]: README.md#setup-instructions
+[req]: index.md#setup-instructions

doc/gitlab-geo/README.md

-This document was moved to [another location](../administration/geo/index.md).
+This document was moved to [another location](../administration/geo/replication/index.md).

doc/gitlab-geo/configuration.md

-This document was moved to [another location](../administration/geo/configuration.md).
+This document was moved to [another location](../administration/geo/replication/configuration.md).

doc/gitlab-geo/configuration_source.md

-This document was moved to [another location](../administration/geo/configuration_source.md).
+This document was moved to [another location](../administration/geo/replication/configuration_source.md).

doc/gitlab-geo/database.md

-This document was moved to [another location](../administration/geo/database.md).
+This document was moved to [another location](../administration/geo/replication/database.md).

doc/gitlab-geo/database_source.md

-This document was moved to [another location](../administration/geo/database_source.md).
+This document was moved to [another location](../administration/geo/replication/database_source.md).

doc/gitlab-geo/docker_registry.md

-This document was moved to [another location](../administration/geo/docker_registry.md).
+This document was moved to [another location](../administration/geo/replication/docker_registry.md).

doc/gitlab-geo/faq.md

-This document was moved to [another location](../administration/geo/faq.md).
+This document was moved to [another location](../administration/geo/replication/faq.md).

doc/gitlab-geo/ha.md

-This document was moved to [another location](../administration/geo/high_availability.md).
+This document was moved to [another location](../administration/geo/replication/high_availability.md).

doc/gitlab-geo/object_storage.md

-This document was moved to [another location](../administration/geo/object_storage.md).
+This document was moved to [another location](../administration/geo/replication/object_storage.md).

doc/gitlab-geo/security-review.md

-This document was moved to [another location](../administration/geo/security_review.md).
+This document was moved to [another location](../administration/geo/replication/security_review.md).

doc/gitlab-geo/troubleshooting.md

-This document was moved to [another location](../administration/geo/troubleshooting.md).
+This document was moved to [another location](../administration/geo/replication/troubleshooting.md).

doc/gitlab-geo/tuning.md

-This document was moved to [another location](../administration/geo/tuning.md).
+This document was moved to [another location](../administration/geo/replication/tuning.md).

doc/gitlab-geo/updating_the_geo_nodes.md

-This document was moved to [another location](../administration/geo/updating_the_geo_nodes.md).
+This document was moved to [another location](../administration/geo/replication/updating_the_geo_nodes.md).

doc/gitlab-geo/using_a_geo_server.md

-This document was moved to [another location](../administration/geo/using_a_geo_server.md).
+This document was moved to [another location](../administration/geo/replication/using_a_geo_server.md).