Add latest changes from gitlab-org/gitlab@master

5 files changed, 11 insertions, 8 deletions

diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index f1af83d0b39..3008cea365c 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -612,7 +612,7 @@ To check the configuration:
 
    If everything is working, you should see something like this:
 
-   ```
+   ```plaintext
    gitlabhq_geo_production=# SELECT * from information_schema.foreign_tables;
      foreign_table_catalog  | foreign_table_schema |               foreign_table_name                | foreign_server_catalog  | foreign_server_name
    -------------------------+----------------------+-------------------------------------------------+-------------------------+---------------------
diff --git a/doc/administration/high_availability/database.md b/doc/administration/high_availability/database.md
index 8278d667fea..4362ed3e64b 100644
--- a/doc/administration/high_availability/database.md
+++ b/doc/administration/high_availability/database.md
@@ -920,7 +920,7 @@ after it has been restored to service.
   Once `repmgrd` and PostgreSQL are runnning, the node will need to follow the new
   as a standby node.
 
-  ```
+  ```shell
   gitlab-ctl repmgr standby follow NEW_MASTER
   ```
 
@@ -930,7 +930,7 @@ after it has been restored to service.
   Once the old master node has been unregistered from the cluster, it will need
   to be setup as a new standby:
 
-  ```
+  ```shell
   gitlab-ctl repmgr standby setup NEW_MASTER
   ```
 
diff --git a/doc/administration/monitoring/ip_whitelist.md b/doc/administration/monitoring/ip_whitelist.md
index 6bb2fe81b2c..700bcc978e0 100644
--- a/doc/administration/monitoring/ip_whitelist.md
+++ b/doc/administration/monitoring/ip_whitelist.md
@@ -2,6 +2,9 @@
 
 > Introduced in GitLab 9.4.
 
+NOTE: **Note:**
+We intend to [rename IP whitelist as `IP allowlist`](https://gitlab.com/gitlab-org/gitlab/-/issues/7554).
+
 GitLab provides some [monitoring endpoints] that provide health check information
 when probed.
 
diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md
index 896c08d7a43..ba0d511b718 100644
--- a/doc/administration/repository_storage_types.md
+++ b/doc/administration/repository_storage_types.md
@@ -93,7 +93,7 @@ open up the page for the project.
 
 The "Gitaly relative path" is shown there, for example:
 
-```
+```plaintext
 "@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git"
 ```
 
@@ -126,7 +126,7 @@ with `.git` from the end of the directory name removed.
 
 The output includes the project id and the project name:
 
-```
+```plaintext
 => #<Project id:16 it/supportteam/ticketsystem>
 ```
 
diff --git a/doc/administration/troubleshooting/postgresql.md b/doc/administration/troubleshooting/postgresql.md
index b793f0a2ebc..966db356849 100644
--- a/doc/administration/troubleshooting/postgresql.md
+++ b/doc/administration/troubleshooting/postgresql.md
@@ -121,8 +121,8 @@ In this case, the guidance we had from development was to drop deadlock_timeout
 
 PostgresSQL defaults:
 
-- statement_timeout = 0 (never)
-- idle_in_transaction_session_timeout = 0 (never)
+- `statement_timeout = 0` (never)
+- `idle_in_transaction_session_timeout = 0` (never)
 
 Comments in issue [#1](https://gitlab.com/gitlab-org/gitlab/issues/30528) indicate that these should both be set to at least a number of minutes for all Omnibus installations (so they don't hang indefinitely). However, 15s for statement_timeout is very short, and will only be effective if the underlying infrastructure is very performant.
 
@@ -136,7 +136,7 @@ puts c.execute('SHOW idle_in_transaction_session_timeout').to_a ;"
 
 It may take a little while to respond.
 
-```
+```ruby
 {"statement_timeout"=>"1min"}
 {"lock_timeout"=>"0"}
 {"idle_in_transaction_session_timeout"=>"1min"}