Automatic merge of gitlab-org/gitlab-ce master

doc/administration/geo/disaster_recovery/background_verification.md

@@ -143,11 +143,13 @@ If the **primary** and **secondary** nodes have a checksum verification mismatch
 1. On the project admin page get the **Gitaly storage name**, and **Gitaly relative path**:
    ![Project admin page](img/checksum-differences-admin-project-page.png)
 
-1. Navigate to the project's repository directory on both **primary** and **secondary** nodes (the path is usually `/var/opt/gitlab/git-data/repositories`). Note that if `git_data_dirs` is customized, check the directory layout on your server to be sure.
+1. Navigate to the project's repository directory on both **primary** and **secondary** nodes
+   (the path is usually `/var/opt/gitlab/git-data/repositories`). Note that if `git_data_dirs`
+   is customized, check the directory layout on your server to be sure.
 
-    ```sh
-    cd /var/opt/gitlab/git-data/repositories
-    ```
+   ```sh
+   cd /var/opt/gitlab/git-data/repositories
+   ```
 
 1. Run the following command on the **primary** node, redirecting the output to a file:
 

doc/administration/geo/disaster_recovery/bring_primary_back.md

@@ -21,20 +21,20 @@ To bring the former **primary** node up to date:
 1. SSH into the former **primary** node that has fallen behind.
 1. Make sure all the services are up:
 
-    ```sh
-    sudo gitlab-ctl start
-    ```
-
-    > **Note 1:** If you [disabled the **primary** node permanently][disaster-recovery-disable-primary],
-    > you need to undo those steps now. For Debian/Ubuntu you just need to run
-    > `sudo systemctl enable gitlab-runsvdir`. For CentOS 6, you need to install
-    > the GitLab instance from scratch and set it up as a **secondary** node by
-    > following [Setup instructions][setup-geo]. In this case, you don't need to follow the next step.
-    >
-    > **Note 2:** If you [changed the DNS records](index.md#step-4-optional-updating-the-primary-domain-dns-record)
-    > for this node during disaster recovery procedure you may need to [block
-    > all the writes to this node](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/gitlab-geo/planned-failover.md#block-primary-traffic)
-    > during this procedure.
+   ```sh
+   sudo gitlab-ctl start
+   ```
+
+   NOTE: **Note:** If you [disabled the **primary** node permanently][disaster-recovery-disable-primary],
+   you need to undo those steps now. For Debian/Ubuntu you just need to run
+   `sudo systemctl enable gitlab-runsvdir`. For CentOS 6, you need to install
+   the GitLab instance from scratch and set it up as a **secondary** node by
+   following [Setup instructions][setup-geo]. In this case, you don't need to follow the next step.
+   
+   NOTE: **Note:** If you [changed the DNS records](index.md#step-4-optional-updating-the-primary-domain-dns-record)
+   for this node during disaster recovery procedure you may need to [block
+   all the writes to this node](planned_failover.md#prevent-updates-to-the-primary-node)
+   during this procedure.
 
 1. [Setup database replication][database-replication]. Note that in this
    case, **primary** node refers to the current **primary** node, and **secondary** node refers to the

doc/administration/geo/disaster_recovery/planned_failover.md

@@ -143,26 +143,26 @@ access to the **primary** node during the maintenance window.
    all HTTP, HTTPS and SSH traffic to/from the **primary** node, **except** for your IP and
    the **secondary** node's IP.
 
-    For instance, you might run the following commands on the server(s) making up your **primary** node:
+   For instance, you might run the following commands on the server(s) making up your **primary** node:
 
-    ```sh
-    sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 22 -j ACCEPT
-    sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 22 -j ACCEPT
-    sudo iptables -A INPUT --destination-port 22 -j REJECT
+   ```sh
+   sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 22 -j ACCEPT
+   sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 22 -j ACCEPT
+   sudo iptables -A INPUT --destination-port 22 -j REJECT
 
-    sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 80 -j ACCEPT
-    sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 80 -j ACCEPT
-    sudo iptables -A INPUT --tcp-dport 80 -j REJECT
+   sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 80 -j ACCEPT
+   sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 80 -j ACCEPT
+   sudo iptables -A INPUT --tcp-dport 80 -j REJECT
 
-    sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 443 -j ACCEPT
-    sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 443 -j ACCEPT
-    sudo iptables -A INPUT --tcp-dport 443 -j REJECT
-    ```
+   sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 443 -j ACCEPT
+   sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 443 -j ACCEPT
+   sudo iptables -A INPUT --tcp-dport 443 -j REJECT
+   ```
 
-    From this point, users will be unable to view their data or make changes on the
-    **primary** node. They will also be unable to log in to the **secondary** node.
-    However, existing sessions will work for the remainder of the maintenance period, and
-    public data will be accessible throughout.
+   From this point, users will be unable to view their data or make changes on the
+   **primary** node. They will also be unable to log in to the **secondary** node.
+   However, existing sessions will work for the remainder of the maintenance period, and
+   public data will be accessible throughout.
 
 1. Verify the **primary** node is blocked to HTTP traffic by visiting it in browser via
    another IP. The server should refuse connection.
@@ -187,10 +187,11 @@ access to the **primary** node during the maintenance window.
    before it is completed will cause the work to be lost.
 1. On the **primary** node, navigate to **Admin Area > Geo** and wait for the
    following conditions to be true of the **secondary** node you are failing over to:
-    - All replication meters to each 100% replicated, 0% failures.
-    - All verification meters reach 100% verified, 0% failures.
-    - Database replication lag is 0ms.
-    - The Geo log cursor is up to date (0 events behind).
+   
+   - All replication meters to each 100% replicated, 0% failures.
+   - All verification meters reach 100% verified, 0% failures.
+   - Database replication lag is 0ms.
+   - The Geo log cursor is up to date (0 events behind).
 
 1. On the **secondary** node, navigate to **Admin Area > Monitoring > Background Jobs > Queues**
    and wait for all the `geo` queues to drop to 0 queued and 0 running jobs.

doc/administration/geo/replication/configuration.md

@@ -16,11 +16,10 @@ The basic steps of configuring a **secondary** node are to:
 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 for 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
-  **primary** node because the **secondary** node is a read-only replica.
+NOTE: **Note:**
+**Do not** set up any custom authentication for 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
+**primary** node because the **secondary** node is a read-only replica.
 
 ### Step 1. Manually replicate secret GitLab values
 
@@ -31,47 +30,47 @@ they must be manually replicated to the **secondary** node.
 
 1. SSH into the **primary** node, and execute the command below:
 
-    ```sh
-    sudo cat /etc/gitlab/gitlab-secrets.json
-    ```
+   ```sh
+   sudo cat /etc/gitlab/gitlab-secrets.json
+   ```
 
-    This will display the secrets that need to be replicated, in JSON format.
+   This will display the secrets that need to be replicated, in JSON format.
 
 1. SSH into the **secondary** node and login as the `root` user:
 
-    ```sh
-    sudo -i
-    ```
+   ```sh
+   sudo -i
+   ```
 
 1. Make a backup of any existing secrets:
 
-    ```sh
-    mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`
-    ```
+   ```sh
+   mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`
+   ```
 
 1. Copy `/etc/gitlab/gitlab-secrets.json` from the **primary** node to the **secondary** node, or
    copy-and-paste the file contents between nodes:
 
-    ```sh
-    sudo editor /etc/gitlab/gitlab-secrets.json
+   ```sh
+   sudo editor /etc/gitlab/gitlab-secrets.json
 
-    # paste the output of the `cat` command you ran on the primary
-    # save and exit
-    ```
+   # paste the output of the `cat` command you ran on the primary
+   # save and exit
+   ```
 
 1. Ensure the file permissions are correct:
 
-    ```sh
-    chown root:root /etc/gitlab/gitlab-secrets.json
-    chmod 0600 /etc/gitlab/gitlab-secrets.json
-    ```
+   ```sh
+   chown root:root /etc/gitlab/gitlab-secrets.json
+   chmod 0600 /etc/gitlab/gitlab-secrets.json
+   ```
 
 1. Reconfigure the **secondary** node for the change to take effect:
 
-    ```sh
-    gitlab-ctl reconfigure
-    gitlab-ctl restart
-    ```
+   ```sh
+   gitlab-ctl reconfigure
+   gitlab-ctl restart
+   ```
 
 ### Step 2. Manually replicate the **primary** node's SSH host keys
 
@@ -89,80 +88,80 @@ keys must be manually replicated to the **secondary** node.
 
 1. SSH into the **secondary** node and login as the `root` user:
 
-    ```sh
-    sudo -i
-    ```
+   ```sh
+   sudo -i
+   ```
 
 1. Make a backup of any existing SSH host keys:
 
-    ```sh
-    find /etc/ssh -iname ssh_host_* -exec cp {} {}.backup.`date +%F` \;
-    ```
+   ```sh
+   find /etc/ssh -iname ssh_host_* -exec cp {} {}.backup.`date +%F` \;
+   ```
 
 1. Copy OpenSSH host keys from the **primary** node:
 
-    If you can access your **primary** node using the **root** user:
+   If you can access your **primary** node using the **root** user:
 
-    ```sh
-    # Run this from the secondary node, change `<primary_node_fqdn>` for the IP or FQDN of the server
-    scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh
-    ```
+   ```sh
+   # Run this from the secondary node, change `<primary_node_fqdn>` for the IP or FQDN of the server
+   scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh
+   ```
 
-    If you only have access through a user with **sudo** privileges:
+   If you only have access through a user with **sudo** privileges:
 
-    ```sh
-    # Run this from your primary node:
-    sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz /etc/ssh/ssh_host_*_key*
+   ```sh
+   # Run this from your primary node:
+   sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz /etc/ssh/ssh_host_*_key*
 
-    # Run this from your secondary node:
-    scp <user_with_sudo>@<primary_node_fqdn>:geo-host-key.tar.gz .
-    tar zxvf ~/geo-host-key.tar.gz -C /etc/ssh
-    ```
+   # Run this from your secondary node:
+   scp <user_with_sudo>@<primary_node_fqdn>:geo-host-key.tar.gz .
+   tar zxvf ~/geo-host-key.tar.gz -C /etc/ssh
+   ```
 
 1. On your **secondary** node, ensure the file permissions are correct:
 
-    ```sh
-    chown root:root /etc/ssh/ssh_host_*_key*
-    chmod 0600 /etc/ssh/ssh_host_*_key*
-    ```
+   ```sh
+   chown root:root /etc/ssh/ssh_host_*_key*
+   chmod 0600 /etc/ssh/ssh_host_*_key*
+   ```
 
 1. To verify key fingerprint matches, execute the following command on both nodes:
 
-    ```sh
-    for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
-    ```
+   ```sh
+   for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
+   ```
 
-    You should get an output similar to this one and they should be identical on both nodes:
+   You should get an output similar to this one and they should be identical on both nodes:
 
-    ```sh
-    1024 SHA256:FEZX2jQa2bcsd/fn/uxBzxhKdx4Imc4raXrHwsbtP0M root@serverhostname (DSA)
-    256 SHA256:uw98R35Uf+fYEQ/UnJD9Br4NXUFPv7JAUln5uHlgSeY root@serverhostname (ECDSA)
-    256 SHA256:sqOUWcraZQKd89y/QQv/iynPTOGQxcOTIXU/LsoPmnM root@serverhostname (ED25519)
-    2048 SHA256:qwa+rgir2Oy86QI+PZi/QVR+MSmrdrpsuH7YyKknC+s root@serverhostname (RSA)
-    ```
+   ```sh
+   1024 SHA256:FEZX2jQa2bcsd/fn/uxBzxhKdx4Imc4raXrHwsbtP0M root@serverhostname (DSA)
+   256 SHA256:uw98R35Uf+fYEQ/UnJD9Br4NXUFPv7JAUln5uHlgSeY root@serverhostname (ECDSA)
+   256 SHA256:sqOUWcraZQKd89y/QQv/iynPTOGQxcOTIXU/LsoPmnM root@serverhostname (ED25519)
+   2048 SHA256:qwa+rgir2Oy86QI+PZi/QVR+MSmrdrpsuH7YyKknC+s root@serverhostname (RSA)
+   ```
 
 1. Verify that you have the correct public keys for the existing private keys:
 
-    ```sh
-    # This will print the fingerprint for private keys:
-    for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
+   ```sh
+   # This will print the fingerprint for private keys:
+   for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
 
-    # This will print the fingerprint for public keys:
-    for file in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf $file; done
-    ```
+   # This will print the fingerprint for public keys:
+   for file in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf $file; done
+   ```
 
-    NOTE: **Note**:
-    The output for private keys and public keys command should generate the same fingerprint.
+   NOTE: **Note:**
+   The output for private keys and public keys command should generate the same fingerprint.
 
 1. Restart sshd on your **secondary** node:
 
-    ```sh
-    # Debian or Ubuntu installations
-    sudo service ssh reload
+   ```sh
+   # Debian or Ubuntu installations
+   sudo service ssh reload
 
-    # CentOS installations
-    sudo service sshd reload
-    ```
+   # CentOS installations
+   sudo service sshd reload
+   ```
 
 ### Step 3. Add the **secondary** node
 
@@ -176,22 +175,22 @@ keys must be manually replicated to the **secondary** node.
 1. Click the **Add node** button.
 1. SSH into your GitLab **secondary** server and restart the services:
 
-    ```sh
-    gitlab-ctl restart
-    ```
+   ```sh
+   gitlab-ctl restart
+   ```
 
-    Check if there are any common issue with your Geo setup by running:
+   Check if there are any common issue with your Geo setup by running:
 
-    ```sh
-    gitlab-rake gitlab:geo:check
-    ```
+   ```sh
+   gitlab-rake gitlab:geo:check
+   ```
 
 1. SSH into your **primary** server and login as root to verify the
    **secondary** node is reachable or there are any common issue with your Geo setup:
 
-    ```sh
-    gitlab-rake gitlab:geo:check
-    ```
+   ```sh
+   gitlab-rake gitlab:geo:check
+   ```
 
 Once added to the admin panel and restarted, the **secondary** node will automatically start
 replicating missing data from the **primary** node in a process known as **backfill**.
@@ -250,9 +249,8 @@ The two most obvious issues that can become apparent in the dashboard are:
 1. Database replication not working well.
 1. Instance to instance notification not working. In that case, it can be
    something of the following:
-     - You are using a custom certificate or custom CA (see the
-       [troubleshooting document]).
-     - The instance is firewalled (check your firewall rules).
+   - You are using a custom certificate or custom CA (see the [troubleshooting document](troubleshooting.md)).
+   - The instance is firewalled (check your firewall rules).
 
 Please note that disabling a **secondary** node will stop the synchronization process.
 
@@ -304,5 +302,4 @@ See the [troubleshooting document](troubleshooting.md).
 [gitlab-org/gitlab-ee#3789]: https://gitlab.com/gitlab-org/gitlab-ee/issues/3789
 [gitlab-com/infrastructure#2821]: https://gitlab.com/gitlab-com/infrastructure/issues/2821
 [omnibus-ssl]: https://docs.gitlab.com/omnibus/settings/ssl.html
-[troubleshooting document]: troubleshooting.md
 [using-geo]: using_a_geo_server.md

doc/administration/geo/replication/external_database.md

@@ -4,7 +4,7 @@ This document is relevant if you are using a PostgreSQL instance that is *not
 managed by Omnibus*. This includes cloud-managed instances like AWS RDS, or
 manually installed and configured PostgreSQL instances.
 
-NOTE: **Note**:
+NOTE: **Note:**
 We strongly recommend running Omnibus-managed instances as they are actively
 developed and tested. We aim to be compatible with most external
 (not managed by Omnibus) databases but we do not guarantee compatibility.
@@ -13,17 +13,17 @@ developed and tested. We aim to be compatible with most external
 
 1. SSH into a GitLab **primary** application server and login as root:
 
-    ```sh
-    sudo -i
-    ```
+   ```sh
+   sudo -i
+   ```
 
 1. Execute the command below to define the node as **primary** node:
 
-    ```sh
-    gitlab-ctl set-geo-primary-node
-    ```
+   ```sh
+   gitlab-ctl set-geo-primary-node
+   ```
 
-    This command will use your defined `external_url` in `/etc/gitlab/gitlab.rb`.
+   This command will use your defined `external_url` in `/etc/gitlab/gitlab.rb`.
 
 
 ### Configure the external database to be replicated
@@ -101,26 +101,27 @@ To configure the connection to the external read-replica database and enable Log
 
 1. SSH into a GitLab **secondary** application server and login as root:
 
-    ```bash
-    sudo -i
-    ```
+   ```bash
+   sudo -i
+   ```
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following
 
-    ```ruby
-    ##
-    ## Geo Secondary role
-    ## - configure dependent flags automatically to enable Geo
-    ##
-    roles ['geo_secondary_role']
+   ```ruby
+   ##
+   ## Geo Secondary role
+   ## - configure dependent flags automatically to enable Geo
+   ##
+   roles ['geo_secondary_role']
+
+   # note this is shared between both databases,
+   # make sure you define the same password in both
+   gitlab_rails['db_password'] = '<your_password_here>'
 
-    # note this is shared between both databases,
-    # make sure you define the same password in both
-    gitlab_rails['db_password'] = '<your_password_here>'
+   gitlab_rails['db_username'] = 'gitlab'
+   gitlab_rails['db_host'] = '<database_read_replica_host>'
+   ```
 
-    gitlab_rails['db_username'] = 'gitlab'
-    gitlab_rails['db_host'] = '<database_read_replica_host>'
-    ```
 1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
 
 ### Configure the tracking database
@@ -147,73 +148,72 @@ the tracking database on port 5432.
 
 1. SSH into a GitLab **secondary** server and login as root:
 
-    ```bash
-    sudo -i
-    ```
+   ```bash
+   sudo -i
+   ```
 
 1. Edit `/etc/gitlab/gitlab.rb` with the connection params and credentials for
-    the machine with the PostgreSQL instance:
+   the machine with the PostgreSQL instance:
 
-    ```ruby
-    geo_secondary['db_username'] = 'gitlab_geo'
-    geo_secondary['db_password'] = '<your_password_here>'
+   ```ruby
+   geo_secondary['db_username'] = 'gitlab_geo'
+   geo_secondary['db_password'] = '<your_password_here>'
 
-    geo_secondary['db_host'] = '<tracking_database_host>'
-    geo_secondary['db_port'] = <tracking_database_port>      # change to the correct port
-    geo_secondary['db_fdw'] = true       # enable FDW
-    geo_postgresql['enable'] = false     # don't use internal managed instance
-    ```
+   geo_secondary['db_host'] = '<tracking_database_host>'
+   geo_secondary['db_port'] = <tracking_database_port>      # change to the correct port
+   geo_secondary['db_fdw'] = true       # enable FDW
+   geo_postgresql['enable'] = false     # don't use internal managed instance
+   ```
 
 1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
 
 1. Run the tracking database migrations:
 
-    ```bash
-    gitlab-rake geo:db:create
-    gitlab-rake geo:db:migrate
-    ```
-
-1. Configure the
-    [PostgreSQL FDW](https://www.postgresql.org/docs/9.6/static/postgres-fdw.html)
-    connection and credentials:
-
-    Save the script below in a file, ex. `/tmp/geo_fdw.sh` and modify the connection
-    params to match your environment. Execute it to set up the FDW connection.
-
-    ```bash
-    #!/bin/bash
-
-    # Secondary Database connection params:
-    DB_HOST="<public_ip_or_vpc_private_ip>"
-    DB_NAME="gitlabhq_production"
-    DB_USER="gitlab"
-    DB_PASS="<your_password_here>"
-    DB_PORT="5432"
-
-    # Tracking Database connection params:
-    GEO_DB_HOST="<public_ip_or_vpc_private_ip>"
-    GEO_DB_NAME="gitlabhq_geo_production"
-    GEO_DB_USER="gitlab_geo"
-    GEO_DB_PORT="5432"
-
-    query_exec () {
-      gitlab-psql -h $GEO_DB_HOST -d $GEO_DB_NAME -p $GEO_DB_PORT -c "${1}"
-    }
-
-    query_exec "CREATE EXTENSION postgres_fdw;"
-    query_exec "CREATE SERVER gitlab_secondary FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host '${DB_HOST}', dbname '${DB_NAME}', port '${DB_PORT}');"
-    query_exec "CREATE USER MAPPING FOR ${GEO_DB_USER} SERVER gitlab_secondary OPTIONS (user '${DB_USER}', password '${DB_PASS}');"
-    query_exec "CREATE SCHEMA gitlab_secondary;"
-    query_exec "GRANT USAGE ON FOREIGN SERVER gitlab_secondary TO ${GEO_DB_USER};"
-    ```
-
-    NOTE: **Note:** The script template above uses `gitlab-psql` as it's intended to be executed from the Geo machine,
-    but you can change it to `psql` and run it from any machine that has access to the database. We also recommend using
-    `psql` for AWS RDS.
+   ```bash
+   gitlab-rake geo:db:create
+   gitlab-rake geo:db:migrate
+   ```
+
+1. Configure the [PostgreSQL FDW](https://www.postgresql.org/docs/9.6/static/postgres-fdw.html)
+   connection and credentials:
+
+   Save the script below in a file, ex. `/tmp/geo_fdw.sh` and modify the connection
+   params to match your environment. Execute it to set up the FDW connection.
+
+   ```bash
+   #!/bin/bash
+
+   # Secondary Database connection params:
+   DB_HOST="<public_ip_or_vpc_private_ip>"
+   DB_NAME="gitlabhq_production"
+   DB_USER="gitlab"
+   DB_PASS="<your_password_here>"
+   DB_PORT="5432"
+
+   # Tracking Database connection params:
+   GEO_DB_HOST="<public_ip_or_vpc_private_ip>"
+   GEO_DB_NAME="gitlabhq_geo_production"
+   GEO_DB_USER="gitlab_geo"
+   GEO_DB_PORT="5432"
+
+   query_exec () {
+     gitlab-psql -h $GEO_DB_HOST -d $GEO_DB_NAME -p $GEO_DB_PORT -c "${1}"
+   }
+
+   query_exec "CREATE EXTENSION postgres_fdw;"
+   query_exec "CREATE SERVER gitlab_secondary FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host '${DB_HOST}', dbname '${DB_NAME}', port '${DB_PORT}');"
+   query_exec "CREATE USER MAPPING FOR ${GEO_DB_USER} SERVER gitlab_secondary OPTIONS (user '${DB_USER}', password '${DB_PASS}');"
+   query_exec "CREATE SCHEMA gitlab_secondary;"
+   query_exec "GRANT USAGE ON FOREIGN SERVER gitlab_secondary TO ${GEO_DB_USER};"
+   ```
+
+   NOTE: **Note:** The script template above uses `gitlab-psql` as it's intended to be executed from the Geo machine,
+   but you can change it to `psql` and run it from any machine that has access to the database. We also recommend using
+   `psql` for AWS RDS.
 
 1. Save the file and [restart GitLab](../../restart_gitlab.md#omnibus-gitlab-restart)
 1. Populate the FDW tables:
 
-    ```bash
-    gitlab-rake geo:db:refresh_foreign_tables
-    ```
+   ```bash
+   gitlab-rake geo:db:refresh_foreign_tables
+   ```

doc/administration/geo/replication/high_availability.md

@@ -50,17 +50,17 @@ The following steps enable a GitLab cluster to serve as the **primary** node.
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following:
 
-    ```ruby
-    ##
-    ## Enable the Geo primary role
-    ##
-    roles ['geo_primary_role']
-
-    ##
-    ## Disable automatic migrations
-    ##
-    gitlab_rails['auto_migrate'] = false
-    ```
+   ```ruby
+   ##
+   ## Enable the Geo primary role
+   ##
+   roles ['geo_primary_role']
+
+   ##
+   ## Disable automatic migrations
+   ##
+   gitlab_rails['auto_migrate'] = false
+   ```
 
 After making these changes, [reconfigure GitLab][gitlab-reconfigure] so the changes take effect.
 
@@ -107,36 +107,36 @@ Configure the [**secondary** database](database.md) as a read-only replica of
 the **primary** database. Use the following as a guide.
 
 1. Edit `/etc/gitlab/gitlab.rb` in the replica database machine, and add the
-    following:
-
-    ```ruby
-    ##
-    ## Configure the PostgreSQL role
-    ##
-    roles ['postgres_role']
-
-    ##
-    ## Secondary address
-    ## - replace '<secondary_node_ip>' with the public or VPC address of your Geo secondary node
-    ## - replace '<tracking_database_ip>' with the public or VPC address of your Geo tracking database node
-    ##
-    postgresql['listen_address'] = '<secondary_node_ip>'
-    postgresql['md5_auth_cidr_addresses'] = ['<secondary_node_ip>/32', '<tracking_database_ip>/32']
-
-    ##
-    ## Database credentials password (defined previously in primary node)
-    ## - replicate same values here as defined in primary node
-    ##
-    postgresql['sql_user_password'] = '<md5_hash_of_your_password>'
-    gitlab_rails['db_password'] = '<your_password_here>'
-
-    ##
-    ## When running the Geo tracking database on a separate machine, disable it
-    ## here and allow connections from the tracking database host. And ensure
-    ## the tracking database IP is in postgresql['md5_auth_cidr_addresses'] above.
-    ##
-    geo_postgresql['enable'] = false
-    ```
+   following:
+
+   ```ruby
+   ##
+   ## Configure the PostgreSQL role
+   ##
+   roles ['postgres_role']
+
+   ##
+   ## Secondary address
+   ## - replace '<secondary_node_ip>' with the public or VPC address of your Geo secondary node
+   ## - replace '<tracking_database_ip>' with the public or VPC address of your Geo tracking database node
+   ##
+   postgresql['listen_address'] = '<secondary_node_ip>'
+   postgresql['md5_auth_cidr_addresses'] = ['<secondary_node_ip>/32', '<tracking_database_ip>/32']
+
+   ##
+   ## Database credentials password (defined previously in primary node)
+   ## - replicate same values here as defined in primary node
+   ##
+   postgresql['sql_user_password'] = '<md5_hash_of_your_password>'
+   gitlab_rails['db_password'] = '<your_password_here>'
+
+   ##
+   ## When running the Geo tracking database on a separate machine, disable it
+   ## here and allow connections from the tracking database host. And ensure
+   ## the tracking database IP is in postgresql['md5_auth_cidr_addresses'] above.
+   ##
+   geo_postgresql['enable'] = false
+   ```
 
 After making these changes, [reconfigure GitLab][gitlab-reconfigure] so the changes take effect.
 
@@ -151,47 +151,47 @@ only a single machine, rather than as a PostgreSQL cluster.
 Configure the tracking database.
 
 1. Edit `/etc/gitlab/gitlab.rb` in the tracking database machine, and add the
-    following:
-
-    ```ruby
-    ##
-    ## Enable the Geo secondary tracking database
-    ##
-    geo_postgresql['enable'] = true
-    geo_postgresql['listen_address'] = '<ip_address_of_this_host>'
-    geo_postgresql['sql_user_password'] = '<tracking_database_password_md5_hash>'
-
-    ##
-    ## Configure FDW connection to the replica database
-    ##
-    geo_secondary['db_fdw'] = true
-    geo_postgresql['fdw_external_password'] = '<replica_database_password_plaintext>'
-    geo_postgresql['md5_auth_cidr_addresses'] = ['<replica_database_ip>/32']
-    gitlab_rails['db_host'] = '<replica_database_ip>'
-
-    # Prevent reconfigure from attempting to run migrations on the replica DB
-    gitlab_rails['auto_migrate'] = false
-
-    ##
-    ## Disable all other services that aren't needed, since we don't have a role
-    ## that does this.
-    ##
-    alertmanager['enable'] = false
-    consul['enable'] = false
-    gitaly['enable'] = false
-    gitlab_monitor['enable'] = false
-    gitlab_workhorse['enable'] = false
-    nginx['enable'] = false
-    node_exporter['enable'] = false
-    pgbouncer_exporter['enable'] = false
-    postgresql['enable'] = false
-    prometheus['enable'] = false
-    redis['enable'] = false
-    redis_exporter['enable'] = false
-    repmgr['enable'] = false
-    sidekiq['enable'] = false
-    unicorn['enable'] = false
-    ```
+   following:
+
+   ```ruby
+   ##
+   ## Enable the Geo secondary tracking database
+   ##
+   geo_postgresql['enable'] = true
+   geo_postgresql['listen_address'] = '<ip_address_of_this_host>'
+   geo_postgresql['sql_user_password'] = '<tracking_database_password_md5_hash>'
+
+   ##
+   ## Configure FDW connection to the replica database
+   ##
+   geo_secondary['db_fdw'] = true
+   geo_postgresql['fdw_external_password'] = '<replica_database_password_plaintext>'
+   geo_postgresql['md5_auth_cidr_addresses'] = ['<replica_database_ip>/32']
+   gitlab_rails['db_host'] = '<replica_database_ip>'
+
+   # Prevent reconfigure from attempting to run migrations on the replica DB
+   gitlab_rails['auto_migrate'] = false
+
+   ##
+   ## Disable all other services that aren't needed, since we don't have a role
+   ## that does this.
+   ##
+   alertmanager['enable'] = false
+   consul['enable'] = false
+   gitaly['enable'] = false
+   gitlab_monitor['enable'] = false
+   gitlab_workhorse['enable'] = false
+   nginx['enable'] = false
+   node_exporter['enable'] = false
+   pgbouncer_exporter['enable'] = false
+   postgresql['enable'] = false
+   prometheus['enable'] = false
+   redis['enable'] = false
+   redis_exporter['enable'] = false
+   repmgr['enable'] = false
+   sidekiq['enable'] = false
+   unicorn['enable'] = false
+   ```
 
 After making these changes, [reconfigure GitLab][gitlab-reconfigure] so the changes take effect.
 
@@ -211,50 +211,50 @@ following modifications:
 1. Edit `/etc/gitlab/gitlab.rb` on each application server in the **secondary**
    cluster, and add the following:
 
-    ```ruby
-    ##
-    ## Enable the Geo secondary role
-    ##
-    roles ['geo_secondary_role', 'application_role']
-
-    ##
-    ## Disable automatic migrations
-    ##
-    gitlab_rails['auto_migrate'] = false
-
-    ##
-    ## Configure the connection to the tracking DB. And disable application
-    ## servers from running tracking databases.
-    ##
-    geo_secondary['db_host'] = '<geo_tracking_db_host>'
-    geo_secondary['db_password'] = '<geo_tracking_db_password>'
-    geo_postgresql['enable'] = false
-
-    ##
-    ## Configure connection to the streaming replica database, if you haven't
-    ## already
-    ##
-    gitlab_rails['db_host'] = '<replica_database_host>'
-    gitlab_rails['db_password'] = '<replica_database_password>'
-
-    ##
-    ## Configure connection to Redis, if you haven't already
-    ##
-    gitlab_rails['redis_host'] = '<redis_host>'
-    gitlab_rails['redis_password'] = '<redis_password>'
-
-    ##
-    ## If you are using custom users not managed by Omnibus, you need to specify
-    ## UIDs and GIDs like below, and ensure they match between servers in a
-    ## cluster to avoid permissions issues
-    ##
-    user['uid'] = 9000
-    user['gid'] = 9000
-    web_server['uid'] = 9001
-    web_server['gid'] = 9001
-    registry['uid'] = 9002
-    registry['gid'] = 9002
-    ```
+   ```ruby
+   ##
+   ## Enable the Geo secondary role
+   ##
+   roles ['geo_secondary_role', 'application_role']
+
+   ##
+   ## Disable automatic migrations
+   ##
+   gitlab_rails['auto_migrate'] = false
+
+   ##
+   ## Configure the connection to the tracking DB. And disable application
+   ## servers from running tracking databases.
+   ##
+   geo_secondary['db_host'] = '<geo_tracking_db_host>'
+   geo_secondary['db_password'] = '<geo_tracking_db_password>'
+   geo_postgresql['enable'] = false
+
+   ##
+   ## Configure connection to the streaming replica database, if you haven't
+   ## already
+   ##
+   gitlab_rails['db_host'] = '<replica_database_host>'
+   gitlab_rails['db_password'] = '<replica_database_password>'
+
+   ##
+   ## Configure connection to Redis, if you haven't already
+   ##
+   gitlab_rails['redis_host'] = '<redis_host>'
+   gitlab_rails['redis_password'] = '<redis_password>'
+
+   ##
+   ## If you are using custom users not managed by Omnibus, you need to specify
+   ## UIDs and GIDs like below, and ensure they match between servers in a
+   ## cluster to avoid permissions issues
+   ##
+   user['uid'] = 9000
+   user['gid'] = 9000
+   web_server['uid'] = 9001
+   web_server['gid'] = 9001
+   registry['uid'] = 9002
+   registry['gid'] = 9002
+   ```
 
 NOTE: **Note:**
 If you had set up PostgreSQL cluster using the omnibus package and you had set

doc/administration/geo/replication/index.md

@@ -80,8 +80,8 @@ In this diagram:
 - If present, the [LDAP server](#ldap) should be configured to replicate for [Disaster Recovery](../disaster_recovery/index.md) scenarios.
 - A **secondary** node performs different type of synchronizations against the **primary** node, using a special
   authorization protected by JWT:
-   - Repositories are cloned/updated via Git over HTTPS.
-   - Attachments, LFS objects, and other files are downloaded via HTTPS using a private API endpoint.
+  - Repositories are cloned/updated via Git over HTTPS.
+  - Attachments, LFS objects, and other files are downloaded via HTTPS using a private API endpoint.
 
 From the perspective of a user performing Git operations:
 
@@ -107,8 +107,8 @@ The following are required to run Geo:
 - An operating system that supports OpenSSH 6.9+ (needed for
   [fast lookup of authorized SSH keys in the database](../../operations/fast_ssh_key_lookup.md))
   The following operating systems are known to ship with a current version of OpenSSH:
-    - [CentOS](https://www.centos.org) 7.4+
-    - [Ubuntu](https://www.ubuntu.com) 16.04+
+  - [CentOS](https://www.centos.org) 7.4+
+  - [Ubuntu](https://www.ubuntu.com) 16.04+
 - PostgreSQL 9.6+ with [FDW](https://www.postgresql.org/docs/9.6/postgres-fdw.html) support and [Streaming Replication](https://wiki.postgresql.org/wiki/Streaming_Replication)
 - Git 2.9+
 

doc/administration/geo/replication/remove_geo_node.md

@@ -10,41 +10,42 @@ Once removed from the Geo admin page, you must stop and uninstall the **secondar
 
 1. On the **secondary** node, stop GitLab:
 
-    ```bash
-    sudo gitlab-ctl stop
-    ```
+   ```bash
+   sudo gitlab-ctl stop
+   ```
+
 1. On the **secondary** node, uninstall GitLab:
 
-    ```bash
-    # Stop gitlab and remove its supervision process
-    sudo gitlab-ctl uninstall
+   ```bash
+   # Stop gitlab and remove its supervision process
+   sudo gitlab-ctl uninstall
     
-    # Debian/Ubuntu
-    sudo dpkg --remove gitlab-ee
+   # Debian/Ubuntu
+   sudo dpkg --remove gitlab-ee
     
-    # Redhat/Centos
-    sudo rpm --erase gitlab-ee
-    ```
+   # Redhat/Centos
+   sudo rpm --erase gitlab-ee
+   ```
 
 Once GitLab has been uninstalled from the **secondary** node, the replication slot must be dropped from the **primary** node's database as follows:
 
 1. On the **primary** node, start a PostgreSQL console session:
 
-    ```bash
-    sudo gitlab-psql 
-    ```
+   ```bash
+   sudo gitlab-psql 
+   ```
     
-    NOTE: **Note:**
-    Using `gitlab-rails dbconsole` will not work, because managing replication slots requires superuser permissions.
+   NOTE: **Note:**
+   Using `gitlab-rails dbconsole` will not work, because managing replication slots requires superuser permissions.
 
 1. Find the name of the relevant replication slot. This is the slot that is specified with `--slot-name` when running the replicate command: `gitlab-ctl replicate-geo-database`.
 
-    ```sql
-    SELECT * FROM pg_replication_slots;
-    ```
+   ```sql
+   SELECT * FROM pg_replication_slots;
+   ```
     
 1. Remove the replication slot for the **secondary** node:
 
-    ```sql
-    SELECT pg_drop_replication_slot('<name_of_slot>');
-    ```  
+   ```sql
+   SELECT pg_drop_replication_slot('<name_of_slot>');
+   ```  

doc/api/jobs.md

@@ -14,7 +14,7 @@ GET /projects/:id/jobs
 | `scope`   | string **or** array of strings | no       | Scope of jobs to show. Either one of or an array of the following: `created`, `pending`, `running`, `failed`, `success`, `canceled`, `skipped`, or `manual`. All jobs are returned if `scope` is not provided. |
 
 ```sh
-curl --header "PRIVATE-TOKEN: <your_access_token>" 'https://gitlab.example.com/api/v4/projects/1/jobs?scope[]=pending&scope[]=running'
+curl --globoff --header "PRIVATE-TOKEN: <your_access_token>" 'https://gitlab.example.com/api/v4/projects/1/jobs?scope[]=pending&scope[]=running'
 ```
 
 Example of response

doc/api/project_snippets.md

@@ -13,6 +13,12 @@ Constants for snippet visibility levels are:
 | `internal` | The snippet is visible for any logged in user |
 | `public`   | The snippet can be accessed without any authentication |
 
+NOTE: **Note:**
+From July 2019, the `Internal` visibility setting is disabled for new projects, groups, 
+and snippets on GitLab.com. Existing projects, groups, and snippets using the `Internal`
+visibility setting keep this setting. You can read more about the change in the
+[relevant issue](https://gitlab.com/gitlab-org/gitlab-ee/issues/12388).
+
 ## List snippets
 
 Get a list of project snippets.

doc/public_access/public_access.md

@@ -29,6 +29,12 @@ in users.
 Any logged in user will have [Guest permissions](../user/permissions.md)
 on the repository.
 
+NOTE: **Note:**
+From July 2019, the `Internal` visibility setting is disabled for new projects, groups,
+and snippets on GitLab.com. Existing projects, groups, and snippets using the `Internal`
+visibility setting keep this setting. You can read more about the change in the
+[relevant issue](https://gitlab.com/gitlab-org/gitlab-ee/issues/12388).
+
 ### Private projects
 
 Private projects can only be cloned and viewed by project members.

doc/user/gitlab_com/index.md

@@ -352,3 +352,13 @@ High Performance TCP/HTTP Load Balancer:
 [unicorn-worker-killer]: https://rubygems.org/gems/unicorn-worker-killer "unicorn-worker-killer"
 [4010]: https://gitlab.com/gitlab-com/infrastructure/issues/4010 "Find a good value for maximum timeout for Shared Runners"
 [4070]: https://gitlab.com/gitlab-com/infrastructure/issues/4070 "Configure per-runner timeout for shared-runners-manager-X on GitLab.com"
+
+## Other admin area settings
+
+This area highlights other noteworthy admin area settings on GitLab.com that differ from default settings. This list is not exhaustive.
+
+NOTE: **Note:**
+From July 2019, the `Internal` visibility setting is disabled for new projects, groups, 
+and snippets on GitLab.com. Existing projects, groups, and snippets using the `Internal`
+visibility setting keep this setting. You can read more about the change in the
+[relevant issue](https://gitlab.com/gitlab-org/gitlab-ee/issues/12388).

qa/qa/page/project/operations/kubernetes/show.rb

@@ -28,12 +28,16 @@ module QA
               end
             end
 
-            def await_installed(application_name)
+            def await_installed(application_name, button_text: 'Installed')
               within(".js-cluster-application-row-#{application_name}") do
-                page.has_text?('Installed', wait: 300)
+                page.has_text?(button_text, wait: 300)
               end
             end
 
+            def await_uninstallable(application_name)
+              await_installed(application_name, button_text: 'Uninstall')
+            end
+
             def ingress_ip
               # We need to wait longer since it can take some time before the
               # ip address is assigned for the ingress controller

qa/qa/resource/kubernetes_cluster.rb

@@ -47,7 +47,7 @@ module QA
             page.install!(:runner) if @install_runner
 
             page.await_installed(:ingress) if @install_ingress
-            page.await_installed(:prometheus) if @install_prometheus
+            page.await_uninstallable(:prometheus) if @install_prometheus
             page.await_installed(:runner) if @install_runner
 
             if @install_ingress