Add latest changes from gitlab-org/gitlab@master

9 files changed, 108 insertions, 26 deletions

diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index 3074ebddc3b..ac337ed8da8 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -765,6 +765,14 @@ To specify a timeframe in UTC, run:
 sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml dataloss -from 2020-01-02T00:00:00+00:00 -to 2020-01-02T00:02:00+00:00
 ```
 
+### Checking repository checksums
+
+To check a project's checksums across all nodes, the Praefect replicas Rake task can be used:
+
+```shell
+sudo gitlab-rake "gitlab:praefect:replicas[project_id]"
+```
+
 ## Backend Node Recovery
 
 When a Praefect backend node fails and is no longer able to
diff --git a/doc/administration/logs.md b/doc/administration/logs.md
index a67674de41a..456e0bbc292 100644
--- a/doc/administration/logs.md
+++ b/doc/administration/logs.md
@@ -356,7 +356,11 @@ Changes to group or project settings are logged to this file. For example:
 }
 ```
 
-## `sidekiq.log`
+## Sidekiq Logs
+
+For Omnibus installations, some Sidekiq logs reside in `/var/log/gitlab/sidekiq/current` and as follows.
+
+### `sidekiq.log`
 
 This file lives in `/var/log/gitlab/gitlab-rails/sidekiq.log` for
 Omnibus GitLab packages or in `/home/git/gitlab/log/sidekiq.log` for
@@ -413,7 +417,7 @@ For source installations, edit the `gitlab.yml` and set the Sidekiq
     log_format: json
 ```
 
-## `sidekiq_client.log`
+### `sidekiq_client.log`
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26586) in GitLab 12.9.
 
@@ -517,15 +521,19 @@ I, [2015-02-13T06:17:00.679433 #9291]  INFO -- : Moving existing hooks directory
 
 User clone/fetch activity using SSH transport appears in this log as `executing git command <gitaly-upload-pack...`.
 
-## `current`
+## Gitaly Logs
 
 This file lives in `/var/log/gitlab/gitaly/current` and is produced by [runit](http://smarden.org/runit/). `runit` is packaged with Omnibus and a brief explanation of its purpose is available [in the omnibus documentation](https://docs.gitlab.com/omnibus/architecture/#runit). [Log files are rotated](http://smarden.org/runit/svlogd.8.html), renamed in unix timestamp format and `gzip`-compressed (e.g. `@1584057562.s`).
 
-## `unicorn_stderr.log`
+### `grpc.log`
 
-This file lives in `/var/log/gitlab/unicorn/unicorn_stderr.log` for
-Omnibus GitLab packages or in `/home/git/gitlab/log/unicorn_stderr.log` for
-installations from source.
+This file lives in `/var/log/gitlab/gitlab-rails/grpc.log` for Omnibus GitLab packages. Native [gRPC](https://grpc.io/) logging used by Gitaly.
+
+## `unicorn_stderr.log` & `unicorn_stdout.log`
+
+This file lives in `/var/log/gitlab/unicorn/unicorn_stderr.log` and `/var/log/gitlab/unicorn/unicorn_stdout.log` for
+Omnibus GitLab packages or in `/home/git/gitlab/log/unicorn_stderr.log` and `/home/git/gitlab/log/unicorn_stdout.log`
+for installations from source.
 
 Unicorn is a high-performance forking Web server which is used for
 serving the GitLab application. You can look at this log if, for
@@ -548,6 +556,12 @@ I, [2015-02-13T07:16:01.534501 #13379]  INFO -- : worker=1 spawned pid=13379
 I, [2015-02-13T07:16:01.534848 #13379]  INFO -- : worker=1 ready
 ```
 
+## `puma_stderr.log` & `puma_stdout.log`
+
+This file lives in `/var/log/gitlab/puma/puma_stderr.log` and `/var/log/gitlab/puma/puma_stdout.log` for
+Omnibus GitLab packages or in `/home/git/gitlab/log/puma_stderr.log` and `/home/git/gitlab/log/puma_stdout.log`
+for installations from source.
+
 ## `repocheck.log`
 
 This file lives in `/var/log/gitlab/gitlab-rails/repocheck.log` for
@@ -748,9 +762,60 @@ For Omnibus installations, NGINX logs reside in:
 - `/var/log/gitlab/nginx/gitlab_pages_error.log` contains a log of NGINX errors for Pages static sites.
 - `/var/log/gitlab/nginx/gitlab_registry_access.log` contains a log of requests made to the Container Registry.
 - `/var/log/gitlab/nginx/gitlab_registry_error.log` contains a log of NGINX errors for the Container Regsitry.
+- `/var/log/gitlab/nginx/gitlab_mattermost_access.log` contains a log of requests made to Mattermost.
+- `/var/log/gitlab/nginx/gitlab_mattermost_error.log` contains a log of NGINX errors for Mattermost.
 
 Below is the default GitLab NGINX access log format:
 
 ```plaintext
 $remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"
 ```
+
+## Pages Logs
+
+For Omnibus installations, Pages logs reside in `/var/log/gitlab/gitlab-pages/current`.
+
+For example:
+
+```json
+{
+  "level": "info",
+  "msg": "GitLab Pages Daemon",
+  "revision": "52b2899",
+  "time": "2020-04-22T17:53:12Z",
+  "version": "1.17.0"
+}
+{
+  "level": "info",
+  "msg": "URL: https://gitlab.com/gitlab-org/gitlab-pages",
+  "time": "2020-04-22T17:53:12Z"
+}
+{
+  "gid": 998,
+  "in-place": false,
+  "level": "info",
+  "msg": "running the daemon as unprivileged user",
+  "time": "2020-04-22T17:53:12Z",
+  "uid": 998
+}
+```
+
+## Workhorse Logs
+
+For Omnibus installations, Workhorse logs reside in `/var/log/gitlab/gitlab-workhorse/current`.
+
+## PostgreSQL Logs
+
+For Omnibus installations, PostgreSQL logs reside in `/var/log/gitlab/postgresql/current`.
+
+## Prometheus Logs
+
+For Omnibus installations, Prometheus logs reside in `/var/log/gitlab/prometheus/current`.
+
+## Redis Logs
+
+For Omnibus installations, Redis logs reside in `/var/log/gitlab/redis/current`.
+
+## Mattermost Logs
+
+For Omnibus installations, Mattermost logs reside in `/var/log/gitlab/mattermost/mattermost.log`.
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index 102ae320625..c641b7ec802 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -18,12 +18,17 @@ You can read more about the Docker Registry at
 
 **Omnibus GitLab installations**
 
-If you are using the Omnibus GitLab built in [Let's Encrypt integration](https://docs.gitlab.com/omnibus/settings/ssl.html#lets-encrypt-integration), as of GitLab 12.5, the Container Registry will be automatically enabled on port 5050 of the default domain.
+If you are using the Omnibus GitLab built-in [Let's Encrypt integration](https://docs.gitlab.com/omnibus/settings/ssl.html#lets-encrypt-integration), as of GitLab 12.5, the Container Registry will be automatically enabled on port 5050 of the default domain.
 
-If you would like to use a separate domain, all you have to do is configure the domain name under which the Container
-Registry will listen to. Read
-[#container-registry-domain-configuration](#container-registry-domain-configuration)
-and pick one of the two options that fits your case.
+If you are not using GitLab 12.5 or later, or do not use GitLab's built-in Let's Encrypt
+integration, the GitLab Container Registry must be enabled and
+[configured to use an external domain](#container-registry-domain-configuration).
+
+To enable the GitLab Container Registry on your *existing* GitLab domain, refer to the section on
+[configuring Container Registry to use an existing domain](#configure-container-registry-under-an-existing-gitlab-domain).
+
+To use a *separate* domain with your Container Registry, refer to the section on
+[configuring Container Registry under its own domain](#configure-container-registry-under-its-own-domain).
 
 NOTE: **Note:**
 The container registry works under HTTPS by default. Using HTTP is possible
@@ -650,7 +655,7 @@ notifications:
 
 NOTE: **Note:**
 The garbage collection tools are only available when you've installed GitLab
-via an Omnibus package or the cloud native chart.
+via an Omnibus package or the [cloud native chart](https://docs.gitlab.com/charts/charts/registry/#garbage-collection).
 
 DANGER: **Danger:**
 By running the built-in garbage collection command, it will cause downtime to
diff --git a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
index 1bbecba1da8..662b6a7d50c 100644
--- a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
+++ b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
@@ -230,18 +230,20 @@ to those documents for details.
   ```shell
   minikube start --cpus 3 --memory 8192 # minimum amount for GitLab to work
   minikube addons enable ingress
-  minikube addons enable kube-dns
   ```
 
 - Install Helm via Homebrew and initialize it:
 
   ```shell
-  brew install kubernetes-helm
-  helm init --service-account tiller
+  brew install helm
   ```
 
 - Copy the [Minikube minimum values YAML file](https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube-minimum.yaml)
-  to your workstation.
+  to your workstation:
+
+  ```shell
+  curl --output values.yaml "https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube-minimum.yaml"
+  ```
 
 - Find the IP address in the output of `minikube ip` and update the YAML file with
   this IP address.
@@ -250,7 +252,7 @@ to those documents for details.
 
   ```shell
   helm repo add gitlab https://charts.gitlab.io
-  helm install --name gitlab -f <path-to-yaml-file> gitlab/gitlab
+  helm install gitlab -f <path-to-yaml-file> gitlab/gitlab
   ```
 
   If you want to modify some GitLab settings, you can use the above-mentioned config
diff --git a/doc/api/oauth2.md b/doc/api/oauth2.md
index 959773b217d..a146fdd0d0c 100644
--- a/doc/api/oauth2.md
+++ b/doc/api/oauth2.md
@@ -4,7 +4,7 @@ This document covers using the [OAuth2](https://oauth.net/2/) protocol to allow
 other services to access GitLab resources on user's behalf.
 
 If you want GitLab to be an OAuth authentication service provider to sign into
-other services, see the [OAuth2 provider](../integration/oauth_provider.md)
+other services, see the [OAuth2 authentication service provider](../integration/oauth_provider.md)
 documentation. This functionality is based on the
 [doorkeeper Ruby gem](https://github.com/doorkeeper-gem/doorkeeper).
 
diff --git a/doc/integration/oauth_provider.md b/doc/integration/oauth_provider.md
index 6c9b272f35b..fd1c21d725d 100644
--- a/doc/integration/oauth_provider.md
+++ b/doc/integration/oauth_provider.md
@@ -5,6 +5,8 @@ to sign in to other services.
 
 If you want to use:
 
+- The [OAuth2](https://oauth.net/2/) protocol to access GitLab resources on user's behalf,
+  see [OAuth2 provider](../api/oauth2.md)
 - Other OAuth authentication service providers to sign in to
   GitLab, see the [OAuth2 client documentation](omniauth.md).
 - The related API, see [Applications API](../api/applications.md).
diff --git a/doc/user/application_security/threat_monitoring/index.md b/doc/user/application_security/threat_monitoring/index.md
index 482fceea680..902f8cd2b5b 100644
--- a/doc/user/application_security/threat_monitoring/index.md
+++ b/doc/user/application_security/threat_monitoring/index.md
@@ -38,7 +38,7 @@ about your Ingress traffic:
 
 If a significant percentage of traffic is anomalous, you should
 investigate it for potential threats by
-[examining the application logs](../../clusters/applications.md#web-application-firewall-modsecurity).
+[examining the Web Application Firewall logs](../../clusters/applications.md#web-application-firewall-modsecurity).
 
 ## Container Network Policy
 
diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md
index 47d79ead38f..9cb4d495ced 100644
--- a/doc/user/gitlab_com/index.md
+++ b/doc/user/gitlab_com/index.md
@@ -89,7 +89,7 @@ or over the size limit, you can [reduce your repository size with Git](../projec
 | Repository size including LFS | 10G         | Unlimited     |
 
 NOTE: **Note:**
-A single `git push` is limited to 5GB. LFS is not affected by this limit.
+`git push` and GitLab project imports are limited to 5GB per request. Git LFS and imports other than a file upload are not affected by this limit.
 
 ## IP range
 
diff --git a/doc/user/project/status_page/index.md b/doc/user/project/status_page/index.md
index 5516d84cfe6..02570ff912c 100644
--- a/doc/user/project/status_page/index.md
+++ b/doc/user/project/status_page/index.md
@@ -35,7 +35,7 @@ To use GitLab Status Page you first need to set up your account details for your
 
 ### Status Page project
 
-To deploy the status page to AWS S3 you need to add the Status Page project & configure the necessary CI variables.
+To deploy the Status Page to AWS S3 you need to add the Status Page project & configure the necessary CI variables.
 
 1. Fork the [Status Page](https://gitlab.com/gitlab-org/status-page) project. This can also be done via [Repository Mirroring](https://gitlab.com/gitlab-org/status-page#repository-mirroring) which will ensure you get the up-to-date Status Page features.
 1. Add the following variables in **Settings > CI/CD > Variables**. (To get these variables from Amazon, use your Amazon Console):
@@ -43,7 +43,7 @@ To deploy the status page to AWS S3 you need to add the Status Page project & co
     - `AWS_DEFAULT_REGION` - the AWS region
     - `AWS_ACCESS_KEY_ID` - the AWS access key ID
     - `AWS_SECRET_ACCESS_KEY` - the AWS secret
-1. Run the pipeline to deploy the status page to S3.
+1. Run the pipeline to deploy the Status Page to S3.
 
 ### Syncing incidents to the Status Page
 
@@ -55,7 +55,7 @@ Once the CI/CD variables are set, you'll need to set up the Project you want to
 
 ## Status Page UI
 
-The Status page landing page shows you an overview of the recent incidents. Clicking on an incident will take you to the incident's detail page.
+The Status Page landing page shows you an overview of the recent incidents. Clicking on an incident will take you to the incident's detail page.
 
 ![Status Page landing page](../img/status_page_incidents_v12_10.png)
 
@@ -76,7 +76,7 @@ The incident detail page shows detailed information about a particular incident.
 
 To publish an Incident, you first need to create an issue in the Project you enabled the Status Page settings in.
 
-Once this issue is created, a background worker will publish the issue onto the status page using the credentials you provided during setup.
+Once this issue is created, a background worker will publish the issue onto the Status Page using the credentials you provided during setup.
 
 NOTE: **Note:**
 Confidential issues are not published. If a published issue is made confidential it will be unpublished.
@@ -99,4 +99,4 @@ Anyone with access to view the Issue can add an Emoji Award to a comment, so you
 
 ### Changing the Incident status
 
-To change the incident status from `open` to `closed`, close the incident issue within GitLab. This will then be updated shortly on the Status page website.
+To change the incident status from `open` to `closed`, close the incident issue within GitLab. This will then be updated shortly on the Status Page website.