Add latest changes from gitlab-org/gitlab@master

4 files changed, 107 insertions, 17 deletions

diff --git a/doc/administration/geo/setup/database.md b/doc/administration/geo/setup/database.md
index 05aa026eca1..d72bb0737ae 100644
--- a/doc/administration/geo/setup/database.md
+++ b/doc/administration/geo/setup/database.md
@@ -501,6 +501,79 @@ two other clusters of nodes supporting a Geo **secondary** site. One for the
 main database and the other for the tracking database. For more information,
 see [High Availability with Omnibus GitLab](../../postgresql/replication_and_failover.md).
 
+### Changing the replication password
+
+To change the password for the [replication user](https://wiki.postgresql.org/wiki/Streaming_Replication)
+when using Omnibus-managed PostgreSQL instances:
+
+On the GitLab Geo **primary** server:
+
+1. The default value for the replication user is `gitlab_replicator`, but if you've set a custom replication
+   user in your `/etc/gitlab/gitlab.rb` under the `postgresql['sql_replication_user']` setting, make sure to
+   adapt the following instructions for your own user.
+
+   Generate an MD5 hash of the desired password:
+
+   ```shell
+   sudo gitlab-ctl pg-password-md5 gitlab_replicator
+   # Enter password: <your_password_here>
+   # Confirm password: <your_password_here>
+   # 950233c0dfc2f39c64cf30457c3b7f1e
+   ```
+
+   Edit `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+   # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab_replicator`
+   postgresql['sql_replication_password'] = '<md5_hash_of_your_password>'
+   ```
+
+1. Save the file and reconfigure GitLab to change the replication user's password in PostgreSQL:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. Restart PostgreSQL for the replication password change to take effect:
+
+   ```shell
+   sudo gitlab-ctl restart postgresql
+   ```
+
+Until the password is updated on any **secondary** servers, the [PostgreSQL log](../../logs.md#postgresql-logs) on
+the secondaries will report the following error message:
+
+```console
+FATAL:  could not connect to the primary server: FATAL:  password authentication failed for user "gitlab_replicator"
+```
+
+On all GitLab Geo **secondary** servers:
+
+1. The first step isn't necessary from a configuration perspective, since the hashed `'sql_replication_password'`
+   is not used on the GitLab Geo **secondary**. However in the event that **secondary** needs to be promoted
+   to the GitLab Geo **primary**, make sure to match the `'sql_replication_password'` in the secondary
+   server configuration.
+
+   Edit `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+   # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab_replicator` on the Geo primary
+   postgresql['sql_replication_password'] = '<md5_hash_of_your_password>'
+   ```
+
+1. During the initial replication setup, the `gitlab-ctl replicate-geo-database` command writes the plaintext
+   password for the replication user account to two locations:
+
+   - `gitlab-geo.conf`: Used by the PostgreSQL replication process, written to the PostgreSQL data
+      directory, by default at `/var/opt/gitlab/postgresql/data/gitlab-geo.conf`.
+   - `.pgpass`: Used by the `gitlab-psql` user, located by default at `/var/opt/gitlab/postgresql/.pgpass`.
+
+   Update the plaintext password in both of these files, and restart PostgreSQL:
+
+   ```shell
+   sudo gitlab-ctl restart postgresql
+   ```
+
 ## Multi-node database replication
 
 In GitLab 14.0, Patroni replaced `repmgr` as the supported
diff --git a/doc/development/i18n/externalization.md b/doc/development/i18n/externalization.md
index c383a1cac73..52a7f839286 100644
--- a/doc/development/i18n/externalization.md
+++ b/doc/development/i18n/externalization.md
@@ -790,6 +790,28 @@ translate correctly if you extract individual words from the sentence.
 
 When in doubt, try to follow the best practices described in this [Mozilla Developer documentation](https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_content_best_practices#Splitting).
 
+### Always pass string literals to the translation helpers
+
+The `bin/rake gettext:regenerate` script parses the codebase and extracts all the strings from the
+[translation helpers](#preparing-a-page-for-translation) ready to be translated.
+
+The script cannot resolve the strings if they are passed as variables or function calls. Therefore,
+make sure to always pass string literals to the helpers.
+
+```javascript
+// Good
+__('Some label');
+s__('Namespace', 'Label');
+s__('Namespace|Label');
+n__('%d apple', '%d apples', appleCount);
+
+// Bad
+__(LABEL);
+s__(getLabel());
+s__(NAMESPACE, LABEL);
+n__(LABEL_SINGULAR, LABEL_PLURAL, appleCount);
+```
+
 ## Updating the PO files with the new content
 
 Now that the new content is marked for translation, run this command to update the
diff --git a/doc/integration/elasticsearch.md b/doc/integration/elasticsearch.md
index 9842881094b..5a08a1fe7f3 100644
--- a/doc/integration/elasticsearch.md
+++ b/doc/integration/elasticsearch.md
@@ -902,25 +902,20 @@ Elasticsearch::Transport::Transport::Errors::BadRequest([400] {
 This is because we changed the index mapping in GitLab 8.12 and the old indexes should be removed and built from scratch again,
 see details in the [update guide](../update/upgrading_from_source.md).
 
-- Exception `Elasticsearch::Transport::Transport::Errors::BadRequest`
+### `Elasticsearch::Transport::Transport::Errors::BadRequest`
 
-  If you have this exception (just like in the case above but the actual message is different) please check if you have the correct Elasticsearch version and you met the other [requirements](#system-requirements).
-  There is also an easy way to check it automatically with `sudo gitlab-rake gitlab:check` command.
+If you have this exception (just like in the case above but the actual message is different) please check if you have the correct Elasticsearch version and you met the other [requirements](#system-requirements).
+There is also an easy way to check it automatically with `sudo gitlab-rake gitlab:check` command.
 
-- Exception `Elasticsearch::Transport::Transport::Errors::RequestEntityTooLarge`
+### `Elasticsearch::Transport::Transport::Errors::RequestEntityTooLarge`
 
-  ```plaintext
-  [413] {"Message":"Request size exceeded 10485760 bytes"}
-  ```
+```plaintext
+[413] {"Message":"Request size exceeded 10485760 bytes"}
+```
 
-  This exception is seen when your Elasticsearch cluster is configured to reject
-  requests above a certain size (10MiB in this case). This corresponds to the
-  `http.max_content_length` setting in `elasticsearch.yml`. Increase it to a
-  larger size and restart your Elasticsearch cluster.
+This exception is seen when your Elasticsearch cluster is configured to reject requests above a certain size (10MiB in this case). This corresponds to the `http.max_content_length` setting in `elasticsearch.yml`. Increase it to a larger size and restart your Elasticsearch cluster.
 
-  AWS has [fixed limits](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-limits.html)
-  for this setting ("Maximum Size of HTTP Request Payloads"), based on the size of
-  the underlying instance.
+AWS has [fixed limits](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-limits.html) for this setting ("Maximum Size of HTTP Request Payloads"), based on the size of the underlying instance.
 
 ### My single node Elasticsearch cluster status never goes from `yellow` to `green` even though everything seems to be running properly
 
diff --git a/doc/integration/jira/jira_cloud_configuration.md b/doc/integration/jira/jira_cloud_configuration.md
index e42a102e030..0cfffdb8ba4 100644
--- a/doc/integration/jira/jira_cloud_configuration.md
+++ b/doc/integration/jira/jira_cloud_configuration.md
@@ -11,10 +11,10 @@ on Atlassian cloud. To create the API token:
 
 1. Sign in to [`id.atlassian.com`](https://id.atlassian.com/manage-profile/security/api-tokens)
    with your email address. Use an account with *write* access to Jira projects.
-1. Go to **Settings > API tokens**.
+1. Go to **Settings > Atlassian account settings > Security > Create and manage API tokens**.
 1. Select **Create API token** to display a modal window with an API token.
-1. To copy the API token, select **Copy to clipboard**, or select **View** and write
-   down the new API token. You need this value when you
+1. In the dialog, enter a label for your token and select **Create**.
+1. To copy the API token, select **Copy**, then paste the token somewhere safe. You need this value when you
    [configure GitLab](configure.md).
 
 You need the newly created token, and the email