Add latest changes from gitlab-org/gitlab@13-1-stable-ee

6 files changed, 30 insertions, 14 deletions

diff --git a/doc/administration/operations/extra_sidekiq_processes.md b/doc/administration/operations/extra_sidekiq_processes.md
index 8f54b82c325..155680354da 100644
--- a/doc/administration/operations/extra_sidekiq_processes.md
+++ b/doc/administration/operations/extra_sidekiq_processes.md
@@ -106,14 +106,14 @@ you list:
 
 ## Queue selector (experimental)
 
-> [Introduced](https://gitlab.com/gitlab-com/gl-infra/scalability/issues/45) in [GitLab Starter](https://about.gitlab.com/pricing/) 12.8.
+> [Introduced](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/45) in [GitLab Starter](https://about.gitlab.com/pricing/) 12.8.
 
 CAUTION: **Caution:**
 As this is marked as **experimental**, it is subject to change at any
 time, including **breaking backwards compatibility**. This is so that we
 can react to changes we need for our GitLab.com deployment. We have a
 tracking issue open to [remove the experimental
-designation](https://gitlab.com/gitlab-com/gl-infra/scalability/issues/147)
+designation](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/147)
 from this feature; please comment there if you are interested in using
 this in your own deployment.
 
@@ -126,6 +126,8 @@ in a more general way using the following components:
 
 ### Available attributes
 
+- [Introduced](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/261) in GitLab 13.1, `tags`.
+
 From the [list of all available
 attributes](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/all_queues.yml),
 `experimental_queue_selector` allows selecting of queues by the
@@ -144,14 +146,21 @@ following attributes:
 - `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
   to be selected.
-- `resource_boundary` - if the worker is bound by `cpu`, `memory`, or
+- `resource_boundary` - if the queue is bound by `cpu`, `memory`, or
   `unknown`. For example, the `project_export` queue is memory bound as it has
   to load data in memory before saving it for export.
+- `tags` - short-lived annotations for queues. These are expected to frequently
+  change from release to release, and may be removed entirely.
 
 `has_external_dependencies` is a boolean attribute: only the exact
 string `true` is considered true, and everything else is considered
 false.
 
+`tags` is a set, which means that `=` checks for intersecting sets, and
+`!=` checks for disjoint sets. For example, `tags=a,b` selects queues
+that have tags `a`, `b`, or both. `tags!=a,b` selects queues that have
+neither of those tags.
+
 ### Available operators
 
 `experimental_queue_selector` supports the following operators, listed
diff --git a/doc/administration/operations/fast_ssh_key_lookup.md b/doc/administration/operations/fast_ssh_key_lookup.md
index 6759c3f265d..9f67c927128 100644
--- a/doc/administration/operations/fast_ssh_key_lookup.md
+++ b/doc/administration/operations/fast_ssh_key_lookup.md
@@ -1,7 +1,7 @@
 # Fast lookup of authorized SSH keys in the database
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1631) in [GitLab Starter](https://about.gitlab.com/pricing/) 9.3.
-> - [Available in](https://gitlab.com/gitlab-org/gitlab/issues/3953) GitLab Community Edition 10.4.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1631) in [GitLab Starter](https://about.gitlab.com/pricing/) 9.3.
+> - [Available in](https://gitlab.com/gitlab-org/gitlab/-/issues/3953) GitLab Community Edition 10.4.
 
 NOTE: **Note:** This document describes a drop-in replacement for the
 `authorized_keys` file. For normal (non-deploy key) users, consider using
@@ -125,7 +125,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
    ```shell
    sudo su -
    cd /tmp
-   curl --remote-name https://mirrors.evowise.com/pub/OpenBSD/OpenSSH/portable/openssh-7.5p1.tar.gz
+   curl --remote-name https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-7.5p1.tar.gz
    tar xzvf openssh-7.5p1.tar.gz
    yum install rpm-build gcc make wget openssl-devel krb5-devel pam-devel libX11-devel xmkmf libXt-devel
    ```
diff --git a/doc/administration/operations/filesystem_benchmarking.md b/doc/administration/operations/filesystem_benchmarking.md
index 019909e2e89..c5c5a8b4313 100644
--- a/doc/administration/operations/filesystem_benchmarking.md
+++ b/doc/administration/operations/filesystem_benchmarking.md
@@ -14,7 +14,7 @@ I/O. The information on this page can be used for either scenario.
 ### Benchmarking with `fio`
 
 We recommend using
-[fio](https://fio.readthedocs.io/en/latest/fio_doc.html) to test I/O
+[Fio](https://fio.readthedocs.io/en/latest/fio_doc.html) to test I/O
 performance. This test should be run both on the NFS server and on the
 application nodes that talk to the NFS server.
 
diff --git a/doc/administration/operations/puma.md b/doc/administration/operations/puma.md
index af559cf00e9..af28335ef91 100644
--- a/doc/administration/operations/puma.md
+++ b/doc/administration/operations/puma.md
@@ -10,7 +10,8 @@ Unicorn unless explicitly specified not to.
 ## Why switch to Puma?
 
 Puma has a multi-thread architecture which uses less memory than a multi-process
-application server like Unicorn.
+application server like Unicorn. On GitLab.com, we saw a 40% reduction in memory
+consumption.
 
 Most Rails applications requests normally include a proportion of I/O wait time.
 During I/O wait time MRI Ruby will release the GVL (Global VM Lock) to other threads.
@@ -18,9 +19,15 @@ Multi-threaded Puma can therefore still serve more requests than a single proces
 
 ## Configuring Puma to replace Unicorn
 
-If you are currently running Unicorn and would like to switch to Puma, server configuration
-will _not_ carry over automatically. For details on matching Unicorn configuration settings with
-the Puma equivalent, where applicable, see [Converting Unicorn settings to Puma](https://docs.gitlab.com/omnibus/settings/puma.html#converting-unicorn-settings-to-puma).
+Beginning with GitLab 13.0, Puma is the default application server. We plan to remove support for
+Unicorn in GitLab 14.0.
+
+When switching to Puma, Unicorn server configuration
+will _not_ carry over automatically, due to differences between the two application servers. For Omnibus-based
+deployments, see [Configuring Puma Settings](https://docs.gitlab.com/omnibus/settings/puma.html#configuring-puma-settings).
+For Helm based deployments, see the [Webservice Chart documentation](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
+
+Additionally we strongly recommend that multi-node deployments [configure their load balancers to utilize the readiness check](../high_availability/load_balancer.md#readiness-check) due to a difference between Unicorn and Puma in how they handle connections during a restart of the service.
 
 ## Performance caveat when using Puma with Rugged
 
diff --git a/doc/administration/operations/ssh_certificates.md b/doc/administration/operations/ssh_certificates.md
index b652f282b7b..c81eb15955d 100644
--- a/doc/administration/operations/ssh_certificates.md
+++ b/doc/administration/operations/ssh_certificates.md
@@ -158,7 +158,7 @@ Users can still bypass SSH certificate authentication by manually
 uploading an SSH public key to their profile, relying on the
 `~/.ssh/authorized_keys` fallback to authenticate it. There's
 currently no feature to prevent this, [but there's an open request for
-adding it](https://gitlab.com/gitlab-org/gitlab-foss/issues/49218).
+adding it](https://gitlab.com/gitlab-org/gitlab/-/issues/23260).
 
 Such a restriction can currently be hacked in by e.g. providing a
 custom `AuthorizedKeysCommand` which checks if the discovered key-ID
diff --git a/doc/administration/operations/unicorn.md b/doc/administration/operations/unicorn.md
index 50481482f4c..eabf99eb08c 100644
--- a/doc/administration/operations/unicorn.md
+++ b/doc/administration/operations/unicorn.md
@@ -40,9 +40,9 @@ master process has PID 56227 below.
 [2015-06-05T10:58:08.708824 #62538]  INFO -- : worker=10 ready
 ```
 
-### Tunables
+### Tunable options
 
-The main tunables for Unicorn are the number of worker processes and the
+The main tunable options for Unicorn are the number of worker processes and the
 request timeout after which the Unicorn master terminates a worker process.
 See the [Omnibus GitLab Unicorn settings
 documentation](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/unicorn.md)