Add latest changes from gitlab-org/gitlab@13-12-stable-eev13.12.0-rc42

5 files changed, 34 insertions, 32 deletions

diff --git a/doc/administration/operations/extra_sidekiq_processes.md b/doc/administration/operations/extra_sidekiq_processes.md
index 88e3369e25e..6b8d6f3bf1e 100644
--- a/doc/administration/operations/extra_sidekiq_processes.md
+++ b/doc/administration/operations/extra_sidekiq_processes.md
@@ -144,8 +144,10 @@ attributes](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/all_q
   quickly. Can be `high`, `low`, or `throttled`. For example, the
   `authorized_projects` queue is used to refresh user permissions, and
   is high urgency.
-- `name` - the queue name. The other attributes are typically more useful as
-  they are more general, but this is available in case a particular queue needs
+- `worker_name` - the worker name. The other attributes are typically more useful as
+  they are more general, but this is available in case a particular worker needs
+  to be selected.
+- `name` - the queue name. Similiarly, this is available in case a particular queue needs
   to be selected.
 - `resource_boundary` - if the queue is bound by `cpu`, `memory`, or
   `unknown`. For example, the `project_export` queue is memory bound as it has
diff --git a/doc/administration/operations/fast_ssh_key_lookup.md b/doc/administration/operations/fast_ssh_key_lookup.md
index ec5bf9d6379..980db9713ee 100644
--- a/doc/administration/operations/fast_ssh_key_lookup.md
+++ b/doc/administration/operations/fast_ssh_key_lookup.md
@@ -16,7 +16,7 @@ Regular SSH operations become slow as the number of users grows because OpenSSH
 searches for a key to authorize a user via a linear search. In the worst case,
 such as when the user is not authorized to access GitLab, OpenSSH will scan the
 entire file to search for a key. This can take significant time and disk I/O,
-which will delay users attempting to push or pull to a repository. Making
+which delays users attempting to push or pull to a repository. Making
 matters worse, if users add or remove keys frequently, the operating system may
 not be able to cache the `authorized_keys` file, which causes the disk to be
 accessed repeatedly.
@@ -28,7 +28,7 @@ lookup of authorized SSH keys.
 WARNING:
 OpenSSH version 6.9+ is required because
 `AuthorizedKeysCommand` must be able to accept a fingerprint. These
-instructions will break installations using older versions of OpenSSH, such as
+instructions break installations that use older versions of OpenSSH, such as
 those included with CentOS 6 as of September 2017. If you want to use this
 feature for CentOS 6, follow [the instructions on how to build and install a custom OpenSSH package](#compiling-a-custom-version-of-openssh-for-centos-6) before continuing.
 
@@ -40,9 +40,9 @@ single source of truth, [Geo](../geo/index.md) needs to be configured to perform
 lookups via database lookup.
 
 As part of [setting up Geo](../geo/index.md#setup-instructions),
-you will be required to follow the steps outlined below for both the primary and
+you are required to follow the steps outlined below for both the primary and
 secondary nodes, but note that the `Write to "authorized keys" file` checkbox
-only needs to be unchecked on the primary node since it will be reflected
+only needs to be unchecked on the primary node since it is reflected
 automatically on the secondary if database replication is working.
 
 ## Setting up fast lookup via GitLab Shell
@@ -91,10 +91,10 @@ as required, but that might require temporary ownership changes during `gitlab-s
 
 WARNING:
 Do not disable writes until SSH is confirmed to be working
-perfectly, because the file will quickly become out-of-date.
+perfectly; otherwise, the file quickly becomes out-of-date.
 
 In the case of lookup failures (which are common), the `authorized_keys`
-file will still be scanned. So Git SSH performance will still be slow for many
+file is still scanned. So Git SSH performance would still be slow for many
 users as long as a large file exists.
 
 You can disable any more writes to the `authorized_keys` file by unchecking
@@ -183,8 +183,8 @@ the database. The following instructions can be used to build OpenSSH 7.5:
    -rw-r--r--. 1 root root 367516 Jun 20 19:37 openssh-server-7.5p1-1.x86_64.rpm
    ```
 
-1. Install the packages. OpenSSH packages will replace `/etc/pam.d/sshd`
-   with its own version, which may prevent users from logging in, so be sure
+1. Install the packages. OpenSSH packages replace `/etc/pam.d/sshd`
+   with their own versions, which may prevent users from logging in, so be sure
    that the file is backed up and restored after installation:
 
    ```shell
diff --git a/doc/administration/operations/filesystem_benchmarking.md b/doc/administration/operations/filesystem_benchmarking.md
index 6119fcdae45..ffce104e1ad 100644
--- a/doc/administration/operations/filesystem_benchmarking.md
+++ b/doc/administration/operations/filesystem_benchmarking.md
@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 File system performance has a big impact on overall GitLab performance,
 especially for actions that read or write to Git repositories. This information
-will help benchmark file system performance against known good and bad real-world
+helps benchmark file system performance against known good and bad real-world
 systems.
 
 Normally when talking about file system performance the biggest concern is
@@ -35,12 +35,12 @@ Then run the following:
 fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --bs=4k --iodepth=64 --readwrite=randrw --rwmixread=75 --size=4G --filename=/path/to/git-data/testfile
 ```
 
-This will create a 4GB file in `/path/to/git-data/testfile`. It performs
+This creates a 4GB file in `/path/to/git-data/testfile`. It performs
 4KB reads and writes using a 75%/25% split within the file, with 64
 operations running at a time. Be sure to delete the file after the test
 completes.
 
-The output will vary depending on what version of `fio` installed. The following
+The output varies depending on what version of `fio` installed. The following
 is an example output from `fio` v2.2.10 on a networked solid-state drive (SSD):
 
 ```plaintext
@@ -78,8 +78,8 @@ test but still have poor performance due to read speed and various other
 factors.
 
 The following one-line commands provide a quick benchmark for file system write and read
-performance. This will write 1,000 small files to the directory in which it is
-executed, and then read the same 1,000 files.
+performance. This writes 1,000 small files to the directory in which it is
+executed, and then reads the same 1,000 files.
 
 1. Change into the root of the appropriate
    [repository storage path](../repository_storage_paths.md).
@@ -107,7 +107,7 @@ executed, and then read the same 1,000 files.
   cd ../; rm -rf test
   ```
 
-The output of the `time for ...` commands will look similar to the following. The
+The output of the `time for ...` commands resemble the following. The
 important metric is the `real` time.
 
 ```shell
diff --git a/doc/administration/operations/rails_console.md b/doc/administration/operations/rails_console.md
index 1fe1ea96bff..8c366e311b8 100644
--- a/doc/administration/operations/rails_console.md
+++ b/doc/administration/operations/rails_console.md
@@ -149,17 +149,17 @@ Traceback (most recent call last):
 /opt/gitlab/..../runner_command.rb:42:in `load': cannot load such file -- /tmp/helloworld.rb (LoadError)
 ```
 
-In case you encouter a similar error to this:
+In case you encounter a similar error to this:
 
 ```plaintext
-[root ~]# sudo gitlab-rails runner helloworld.rb 
+[root ~]# sudo gitlab-rails runner helloworld.rb
 Please specify a valid ruby command or the path of a script to run.
 Run 'rails runner -h' for help.
 
 undefined local variable or method `helloworld' for main:Object
 ```
 
-You can either move the file to the `/tmp` directory or create a new directory onwed by the user `git` and save the script in that directory as illustrated below:
+You can either move the file to the `/tmp` directory or create a new directory owned by the user `git` and save the script in that directory as illustrated below:
 
 ```shell
 sudo mkdir /scripts
diff --git a/doc/administration/operations/ssh_certificates.md b/doc/administration/operations/ssh_certificates.md
index c0525cf6258..cc09ad95dce 100644
--- a/doc/administration/operations/ssh_certificates.md
+++ b/doc/administration/operations/ssh_certificates.md
@@ -110,10 +110,10 @@ Where `{KEY_ID}` is the `%i` argument passed to the script
 (e.g. `aeanfjord`), and `{PRINCIPAL}` is the principal passed to it
 (e.g. `sshUsers`).
 
-You will need to customize the `sshUsers` part of that. It should be
+You need to customize the `sshUsers` part of that. It should be
 some principal that's guaranteed to be part of the key for all users
 who can log in to GitLab, or you must provide a list of principals,
-one of which is going to be present for the user, e.g.:
+one of which is present for the user, e.g.:
 
 ```plaintext
     [...]
@@ -122,7 +122,7 @@ one of which is going to be present for the user, e.g.:
 
 ## Principals and security
 
-You can supply as many principals as you want, these will be turned
+You can supply as many principals as you want, these are turned
 into multiple lines of `authorized_keys` output, as described in the
 `AuthorizedPrincipalsFile` documentation in `sshd_config(5)`.
 
@@ -130,32 +130,32 @@ Normally when using the `AuthorizedKeysCommand` with OpenSSH the
 principal is some "group" that's allowed to log into that
 server. However with GitLab it's only used to appease OpenSSH's
 requirement for it, we effectively only care about the "key ID" being
-correct. Once that's extracted GitLab will enforce its own ACLs for
+correct. Once that's extracted GitLab enforces its own ACLs for
 that user (e.g. what projects the user can access).
 
 So it's OK to e.g. be overly generous in what you accept, since if the
-user e.g. has no access to GitLab at all it'll just error out with a
+user e.g. has no access to GitLab at all it just errors out with a
 message about this being an invalid user.
 
 ## Interaction with the `authorized_keys` file
 
 SSH certificates can be used in conjunction with the `authorized_keys`
-file, and if set up as configured above the `authorized_keys` file will
-still serve as a fallback.
+file, and if set up as configured above the `authorized_keys` file
+still serves as a fallback.
 
 This is because if the `AuthorizedPrincipalsCommand` can't
-authenticate the user, OpenSSH will fall back on
+authenticate the user, OpenSSH falls back on
 `~/.ssh/authorized_keys` (or the `AuthorizedKeysCommand`).
 
 Therefore there may still be a reason to use the ["Fast lookup of
 authorized SSH keys in the database"](fast_ssh_key_lookup.html) method
-in conjunction with this. Since you'll be using SSH certificates for
+in conjunction with this. Since you are using SSH certificates for
 all your normal users, and relying on the `~/.ssh/authorized_keys`
 fallback for deploy keys, if you make use of those.
 
 But you may find that there's no reason to do that, since all your
-normal users will use the fast `AuthorizedPrincipalsCommand` path, and
-only automated deployment key access will fall back on
+normal users use the fast `AuthorizedPrincipalsCommand` path, and
+only automated deployment key access falls back on
 `~/.ssh/authorized_keys`, or that you have a lot more keys for normal
 users (especially if they're renewed) than you have deploy keys.
 
@@ -167,14 +167,14 @@ uploading an SSH public key to their profile, relying on the
 currently no feature to prevent this, [but there's an open request for
 adding it](https://gitlab.com/gitlab-org/gitlab/-/issues/23260).
 
-Such a restriction can currently be hacked in by e.g. providing a
+Such a restriction can currently be hacked in by, for example, providing a
 custom `AuthorizedKeysCommand` which checks if the discovered key-ID
 returned from `gitlab-shell-authorized-keys-check` is a deploy key or
 not (all non-deploy keys should be refused).
 
 ## Disabling the global warning about users lacking SSH keys
 
-By default GitLab will show a "You won't be able to pull or push
+By default GitLab shows a "You won't be able to pull or push
 project code via SSH" warning to users who have not uploaded an SSH
 key to their profile.