Merge branch 'geo-docs-new-markup' into 'master'

Use `NOTE:` `CAUTION:` markup

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

doc/administration/geo/replication/configuration.md

 # Geo configuration (GitLab Omnibus)
 
->**Note:**
+NOTE: **Note:**
 This is the documentation for the Omnibus GitLab packages. For installations
 from source, follow the [**Geo nodes configuration for installations
 from source**][configuration-source] guide.
 
 ## Configuring a new secondary node
 
->**Note:**
+NOTE: **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][setup-geo-omnibus].
@@ -20,9 +20,9 @@ You are encouraged to first read through all the steps before executing them
 in your testing/production environment.
 
 > **Notes:**
-- **Do not** setup any custom authentication in the secondary nodes, this will be
+> - **Do not** setup any custom authentication in the secondary nodes, this will be
   handled by the primary node.
-- Any change that requires access to the **Admin Area** needs to be done in the
+> - Any change that requires access to the **Admin Area** needs to be done in the
   primary node, as the secondary node is a read-only replica.
 
 ### Step 1. Manually replicate secret GitLab values

doc/administration/geo/replication/configuration_source.md

 # Geo configuration (source)
 
->**Note:**
+NOTE: **Note:**
 This is the documentation for installations from source. For installations
 using the Omnibus GitLab packages, follow the
 [**Omnibus Geo nodes configuration**][configuration] guide.
 
 ## Configuring a new secondary node
 
->**Note:**
+NOTE: **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][setup-geo-source].
@@ -20,7 +20,7 @@ You are encouraged to first read through all the steps before executing them
 in your testing/production environment.
 
 
->**Notes:**
+NOTE: **Notes:**
 - **Do not** setup any custom authentication in the secondary nodes, this will be
   handled by the primary node.
 - **Do not** add anything in the secondaries Geo nodes admin area

doc/administration/geo/replication/database.md

 # Geo database replication (GitLab Omnibus)
 
->**Note:**
+NOTE: **Note:**
 This is the documentation for the Omnibus GitLab packages. For installations
 from source, follow the
 [**database replication for installations from source**][database-source] guide.
 
->**Note:**
+NOTE: **Note:**
 If your GitLab installation uses external PostgreSQL, the Omnibus roles
 will not be able to perform all necessary configuration steps. Refer to the
 section on [External PostreSQL][external postgresql] for additional instructions.
 
->**Note:**
+NOTE: **Note:**
 The stages of the setup process must be completed in the documented order.
 Before attempting the steps in this stage, [complete all prior stages][toc].
 
@@ -28,7 +28,7 @@ The GitLab primary node where the write operations happen will connect to
 the primary database server, and the secondary nodes which are read-only will
 connect to the secondary database servers (which are also read-only).
 
->**Note:**
+NOTE: **Note:**
 In database documentation you may see "primary" being referenced as "master"
 and "secondary" as either "slave" or "standby" server (read-only).
 
@@ -261,7 +261,8 @@ The following guide assumes that:
     gitlab-ctl stop sidekiq
     ```
 
-   > **Note**: This step is important so we don't try to execute anything before the node is fully configured. 
+    NOTE: **Note**: 
+    This step is important so we don't try to execute anything before the node is fully configured. 
 
 1. [Check TCP connectivity][rake-maintenance] to the primary's PostgreSQL server:
 
@@ -269,7 +270,8 @@ The following guide assumes that:
     gitlab-rake gitlab:tcp_check[1.2.3.4,5432]
     ```
 
-    > **Note**: If this step fails, you may be using the wrong IP address, or a firewall may
+    NOTE: **Note**: 
+    If this step fails, you may be using the wrong IP address, or a firewall may
     be preventing access to the server. Check the IP address, paying close
     attention to the difference between public and private addresses and ensure
     that, if a firewall is present, the secondary is permitted to connect to the
@@ -368,7 +370,7 @@ The directories used are the defaults that are set up in Omnibus. If you have
 changed any defaults or are using a source installation, configure it as you
 see fit replacing the directories and paths.
 
->**Warning:**
+CAUTION: **Warning:**
 Make sure to run this on the **secondary** server as it removes all PostgreSQL's
 data before running `pg_basebackup`.
 
@@ -384,8 +386,8 @@ data before running `pg_basebackup`.
    name as shown in the commands below.
 
 1. Execute the command below to start a backup/restore and begin the replication
-   >**Warning:** Each Geo secondary must have its own unique replication slot name.
-   Using the same slot name between two secondaries will break PostgreSQL replication.
+    CAUTION: **Warning:** Each Geo secondary must have its own unique replication slot name.
+    Using the same slot name between two secondaries will break PostgreSQL replication.
 
     ```bash
     gitlab-ctl replicate-geo-database --slot-name=secondary_example --host=1.2.3.4

doc/administration/geo/replication/database_source.md

 # Geo database replication (source)
 
->**Note:**
+NOTE: **Note:**
 This is the documentation for installations from source. For installations
 using the Omnibus GitLab packages, follow the
 [**database replication for Omnibus GitLab**][database] guide.
 
->**Note:**
+NOTE: **Note:**
 The stages of the setup process must be completed in the documented order.
 Before attempting the steps in this stage, [complete all prior stages][toc].
 
@@ -22,7 +22,7 @@ The GitLab primary node where the write operations happen will connect to
 primary database server, and the secondary ones which are read-only will
 connect to secondary database servers (which are read-only too).
 
->**Note:**
+NOTE: **Note:**
 In many databases documentation you will see "primary" being referenced as "master"
 and "secondary" as either "slave" or "standby" server (read-only).
 
@@ -91,10 +91,11 @@ The following guide assumes that:
 
 1. Set up TLS support for the PostgreSQL primary server
 
-    > **Warning**: Only skip this step if you **know** that PostgreSQL traffic
-    > between the primary and secondary will be secured through some other
-    > means, e.g., a known-safe physical network path or a site-to-site VPN that
-    > you have configured.
+    CAUTION: **Warning**: 
+    Only skip this step if you **know** that PostgreSQL traffic
+    between the primary and secondary will be secured through some other
+    means, e.g., a known-safe physical network path or a site-to-site VPN that
+    you have configured.
 
     If you are replicating your database across the open Internet, it is
     **essential** that the connection is TLS-secured. Correctly configured, this
@@ -141,6 +142,7 @@ The following guide assumes that:
     hot_standby = on
     ```
 
+    NOTE: **Note**:
     Be sure to set `max_replication_slots` to the number of Geo secondary
     nodes that you may potentially have (at least 1).
 
@@ -302,7 +304,7 @@ needed files for streaming replication.
 The directories used are the defaults for Debian/Ubuntu. If you have changed
 any defaults, configure it as you see fit replacing the directories and paths.
 
->**Warning:**
+CAUTION: **Warning:**
 Make sure to run this on the **secondary** server as it removes all PostgreSQL's
 data before running `pg_basebackup`.