Add latest changes from gitlab-org/gitlab@master

18 files changed, 343 insertions, 52 deletions

diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index a8736b3ed1d..9dcca8d0ac5 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -1474,7 +1474,31 @@ Geo::PackageFileRegistry.where(last_sync_failure: 'The file is missing on the Ge
 This iterates over all package files on the secondary, looking at the
 `verification_checksum` stored in the database (which came from the primary)
 and then calculate this value on the secondary to check if they match. This
-does not change anything in the UI:
+does not change anything in the UI.
+
+For GitLab 14.4 and later:
+
+```ruby
+# Run on secondary
+status = {}
+
+Packages::PackageFile.find_each do |package_file|
+  primary_checksum = package_file.verification_checksum
+  secondary_checksum = Packages::PackageFile.sha256_hexdigest(package_file.file.path)
+  verification_status = (primary_checksum == secondary_checksum)
+
+  status[verification_status.to_s] ||= []
+  status[verification_status.to_s] << package_file.id
+end
+
+# Count how many of each value we get
+status.keys.each {|key| puts "#{key} count: #{status[key].count}"}
+
+# See the output in its entirety
+status
+```
+
+For GitLab 14.3 and earlier:
 
 ```ruby
 # Run on secondary
diff --git a/doc/administration/postgresql/replication_and_failover.md b/doc/administration/postgresql/replication_and_failover.md
index 8ac3ac40a75..1f9ed6f3c48 100644
--- a/doc/administration/postgresql/replication_and_failover.md
+++ b/doc/administration/postgresql/replication_and_failover.md
@@ -1076,6 +1076,10 @@ Considering these, you should carefully plan your PostgreSQL upgrade:
    sudo gitlab-ctl pg-upgrade -V 13
    ```
 
+If issues are encountered upgrading the replicas,
+[there is a troubleshooting section](#postgresql-major-version-upgrade-fails-on-a-patroni-replica)
+that might be the solution.
+
 NOTE:
 Reverting the PostgreSQL upgrade with `gitlab-ctl revert-pg-upgrade` has the same considerations as
 `gitlab-ctl pg-upgrade`. You should follow the same procedure by first stopping the replicas,
@@ -1157,7 +1161,7 @@ In addition to the common configuration, you must apply the following in `gitlab
    ```
 
 1. Make sure that Consul agents don't mix PostgreSQL services offered by the existing and the new Patroni
-   clusters. For this purpose, you must use an internal attribute that is currently undocumented:
+   clusters. For this purpose, you must use an internal attribute:
 
    ```ruby
    consul['internal']['postgresql_service_name'] = 'postgresql_new'
@@ -1329,7 +1333,7 @@ If a replica cannot start or rejoin the cluster, or when it lags behind and cann
 
    This can be run on any Patroni node, but be aware that `sudo gitlab-ctl patroni
    reinitialize-replica` without `--member` restarts the server it is run on.
-   It is recommended to run it locally on the broken server to reduce the risk of
+   You should run it locally on the broken server to reduce the risk of
    unintended data loss.
 1. Monitor the logs:
 
@@ -1340,15 +1344,42 @@ If a replica cannot start or rejoin the cluster, or when it lags behind and cann
 ### Reset the Patroni state in Consul
 
 WARNING:
-This is a destructive process and may lead the cluster into a bad state. Make sure that you have a healthy backup before running this process.
+Resetting the Patroni state in Consul is a potentially destructive process. Make sure that you have a healthy database backup first.
+
+As a last resort you can reset the Patroni state in Consul completely.
+
+This may be required if your Patroni cluster is in an unknown or bad state and no node can start:
+
+```plaintext
++ Cluster: postgresql-ha (6970678148837286213) ------+---------+---------+----+-----------+
+| Member                              | Host         | Role    | State   | TL | Lag in MB |
++-------------------------------------+--------------+---------+---------+----+-----------+
+| gitlab-database-1.example.com       | 172.18.0.111 | Replica | stopped |    |   unknown |
+| gitlab-database-2.example.com       | 172.18.0.112 | Replica | stopped |    |   unknown |
+| gitlab-database-3.example.com       | 172.18.0.113 | Replica | stopped |    |   unknown |
++-------------------------------------+--------------+---------+---------+----+-----------+
+```
 
-As a last resort, if your Patroni cluster is in an unknown or bad state and no node can start, you can
-reset the Patroni state in Consul completely, resulting in a reinitialized Patroni cluster when
+**Before deleting the Patroni state in Consul**,
+[try and resolve the `gitlab-ctl` errors](#errors-running-gitlab-ctl) on the Patroni nodes.
+
+This process results in a reinitialized Patroni cluster when
 the first Patroni node starts.
 
 To reset the Patroni state in Consul:
 
-1. Take note of the Patroni node that was the leader, or that the application thinks is the current leader, if the current state shows more than one, or none. One way to do this is to look on the PgBouncer nodes in `/var/opt/gitlab/consul/databases.ini`, which contains the hostname of the current leader.
+1. Take note of the Patroni node that was the leader, or that the application thinks is the current leader,
+   if the current state shows more than one, or none:
+   - Look on the PgBouncer nodes in `/var/opt/gitlab/consul/databases.ini`,
+     which contains the hostname of the current leader.
+   - Look in the Patroni logs `/var/log/gitlab/patroni/current` (or the older rotated and
+     compressed logs `/var/log/gitlab/patroni/@40000*`) on **all** database nodes to see
+     which server was most recently identified as the leader by the cluster:
+
+     ```plaintext
+     INFO: no action. I am a secondary (database1.local) and following a leader (database2.local)
+     ```
+
 1. Stop Patroni on all nodes:
 
    ```shell
@@ -1435,10 +1466,243 @@ Workarounds:
 - If set to enforcing, SELinux may also prevent these operations. Verify the issue is fixed by setting
   SELinux to permissive.
 
-Patroni has been shipping with Omnibus GitLab since 13.1, along with a build of Python 3.7.
-Workarounds should stop being required when GitLab 14.x starts shipping with
-[a later version of Python](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6164) as
-the code which causes this was removed from Python 3.8.
+Patroni first shipped in Omnibus GitLab 13.1, along with a build of Python 3.7.
+The code which causes this was removed in Python 3.8: this fix shipped in
+[Omnibus GitLab 14.3](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5547)
+and later, removing the need for a workaround.
+
+### Errors running `gitlab-ctl`
+
+Patroni nodes can get into a state where `gitlab-ctl` commands fail
+and `gitlab-ctl reconfigure` cannot fix the node.
+
+If this co-incides with a version upgrade of PostgreSQL, [follow a different procedure](#postgresql-major-version-upgrade-fails-on-a-patroni-replica)
+
+One common symptom is that `gitlab-ctl` cannot determine
+information it needs about the installation if the database server is failing to start:
+
+```plaintext
+Malformed configuration JSON file found at /opt/gitlab/embedded/nodes/<HOSTNAME>.json.
+This usually happens when your last run of `gitlab-ctl reconfigure` didn't complete successfully.
+```
+
+```plaintext
+Error while reinitializing replica on the current node: Attributes not found in
+/opt/gitlab/embedded/nodes/<HOSTNAME>.json, has reconfigure been run yet?
+```
+
+Similarly, the nodes file (`/opt/gitlab/embedded/nodes/<HOSTNAME>.json`) should contain a lot of information,
+but might get created with only:
+
+```json
+{
+  "name": "<HOSTNAME>"
+}
+```
+
+The following process for fixing this includes reinitializing this replica:
+the current state of PostgreSQL on this node is discarded:
+
+1. Shut down the Patroni and (if present) PostgreSQL services:
+
+   ```shell
+   sudo gitlab-ctl status
+   sudo gitlab-ctl stop patroni
+   sudo gitlab-ctl stop postgresql
+   ```
+
+1. Remove `/var/opt/gitlab/postgresql/data` in case its state prevents
+   PostgreSQL from starting:
+
+   ```shell
+   cd /var/opt/gitlab/postgresql
+   sudo rm -rf data
+   ```
+
+   **Take care with this step to avoid data loss**.
+   This step can be also achieved by renaming `data/`:
+   make sure there's enough free disk for a new copy of the primary database,
+   and remove the extra directory when the replica is fixed.
+
+1. With PostgreSQL not running, the nodes file now gets created successfully:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. Start Patroni:
+
+   ```shell
+   sudo gitlab-ctl start patroni
+   ```
+
+1. Monitor the logs and check the cluster state:
+
+   ```shell
+   sudo gitlab-ctl tail patroni
+   sudo gitlab-ctl patroni members
+   ```
+
+1. Re-run `reconfigure` again:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. Reinitialize the replica if `gitlab-ctl patroni members` indicates this is needed:
+
+   ```shell
+   sudo gitlab-ctl patroni reinitialize-replica
+   ```
+
+If this procedure doesn't work **and** if the cluster is unable to elect a leader,
+[there is a another fix](#reset-the-patroni-state-in-consul) which should only be
+used as a last resort.
+
+### PostgreSQL major version upgrade fails on a Patroni replica
+
+A Patroni **replica** can get stuck in a loop during `gitlab-ctl pg-upgrade`, and
+the upgrade fails.
+
+An example set of symptoms is as follows:
+
+1. A `postgresql` service is defined,
+   which shouldn't usually be present on a Patroni node. It is present because
+   `gitlab-ctl pg-upgrade` adds it to create a new empty database:
+
+   ```plaintext
+   run: patroni: (pid 1972) 1919s; run: log: (pid 1971) 1919s
+   down: postgresql: 1s, normally up, want up; run: log: (pid 1973) 1919s
+   ```
+
+1. PostgreSQL generates `PANIC` log entries in
+   `/var/log/gitlab/postgresql/current` as Patroni is removing
+   `/var/opt/gitlab/postgresql/data` as part of reinitializing the replica:
+
+   ```plaintext
+   DETAIL:  Could not open file "pg_xact/0000": No such file or directory.
+   WARNING:  terminating connection because of crash of another server process
+   LOG:  all server processes terminated; reinitializing
+   PANIC:  could not open file "global/pg_control": No such file or directory
+   ```
+
+1. In `/var/log/gitlab/patroni/current`, Patroni logs the following.
+   The local PostgreSQL version is different from the cluster leader:
+
+   ```plaintext
+   INFO: trying to bootstrap from leader 'HOSTNAME'
+   pg_basebackup: incompatible server version 12.6
+   pg_basebackup: removing data directory "/var/opt/gitlab/postgresql/data"
+   ERROR: Error when fetching backup: pg_basebackup exited with code=1
+   ```
+
+**Important**: This workaround applies when the Patroni cluster is in the following state:
+
+- The [leader has been successfully upgraded to the new major version](#upgrading-postgresql-major-version-in-a-patroni-cluster).
+- The step to upgrade PostgreSQL on replicas is failing.
+
+This workaround completes the PostgreSQL upgrade on a Patroni replica
+by setting the node to use the new PostgreSQL version, and then reinitializing
+it as a replica in the new cluster that was created
+when the leader was upgraded:
+
+1. Check the cluster status on all nodes to confirm which is the leader
+   and what state the replicas are in
+
+   ```shell
+   sudo gitlab-ctl patroni members
+   ```
+
+1. Replica: check which version of PostgreSQL is active:
+
+   ```shell
+   sudo ls -al /opt/gitlab/embedded/bin | grep postgres
+   ```
+
+1. Replica: ensure the nodes file is correct and `gitlab-ctl` can run. This resolves
+   the [errors running `gitlab-ctl`](#errors-running-gitlab-ctl) issue if the replica
+   has any of those errors as well:
+
+   ```shell
+   sudo gitlab-ctl stop patroni
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. Replica: relink the PostgreSQL binaries to the required version
+   to fix the `incompatible server version` error:
+
+   1. Edit `/etc/gitlab/gitlab.rb` and specify the required version:
+
+      ```ruby
+      postgresql['version'] = 13
+      ```
+
+   1. Reconfigure GitLab:
+
+      ```shell
+      sudo gitlab-ctl reconfigure
+      ```
+
+   1. Check the binaries are relinked. The binaries distributed for
+      PostgreSQL vary between major releases, it's typical to
+      have a small number of incorrect symbolic links:
+
+      ```shell
+      sudo ls -al /opt/gitlab/embedded/bin | grep postgres
+      ```
+
+1. Replica: ensure PostgreSQL is fully reinitialized for the specified version:
+
+   ```shell
+   cd /var/opt/gitlab/postgresql
+   sudo rm -rf data
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. Replica: optionally monitor the database in two additional terminal sessions:
+
+   - Disk use increases as `pg_basebackup` runs. Track progress of the
+     replica initialization with:
+
+     ```shell
+     cd /var/opt/gitlab/postgresql
+     watch du -sh data
+     ```
+
+   - Monitor the process in the logs:
+
+     ```shell
+     sudo gitlab-ctl tail patroni
+     ```
+
+1. Replica: Start Patroni to reinitialize the replica:
+
+   ```shell
+   sudo gitlab-ctl start patroni
+   ```
+
+1. Replica: After it completes, remove the hardcoded version from `/etc/gitlab/gitlab.rb`:
+
+   1. Edit `/etc/gitlab/gitlab.rb` and remove `postgresql['version']`.
+   1. Reconfigure GitLab:
+
+      ```shell
+      sudo gitlab-ctl reconfigure
+      ```
+
+   1. Check the correct binaries are linked:
+
+      ```shell
+      sudo ls -al /opt/gitlab/embedded/bin | grep postgres
+      ```
+
+1. Check the cluster status on all nodes:
+
+   ```shell
+   sudo gitlab-ctl patroni members
+   ```
+
+Repeat this procedure on the other replica if required.
 
 ### Issues with other components
 
diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md
index eba5a03d4dd..ca79fb47aef 100644
--- a/doc/administration/reference_architectures/10k_users.md
+++ b/doc/administration/reference_architectures/10k_users.md
@@ -1045,7 +1045,7 @@ a node and change its status from primary to replica (and vice versa).
    #redis['master_port'] = 6379
 
    # Set up password authentication for Redis and replicas (use the same password in all nodes).
-   redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
+   redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
    redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
 
    ## Must be the same in every Redis node
diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md
index 8222873a082..75d7a897e1a 100644
--- a/doc/administration/reference_architectures/25k_users.md
+++ b/doc/administration/reference_architectures/25k_users.md
@@ -1060,7 +1060,7 @@ a node and change its status from primary to replica (and vice versa).
    #redis['master_port'] = 6379
 
    # Set up password authentication for Redis and replicas (use the same password in all nodes).
-   redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
+   redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
    redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
 
    ## Must be the same in every Redis node
diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md
index 717b4a1b4dd..c3ad595ae54 100644
--- a/doc/administration/reference_architectures/50k_users.md
+++ b/doc/administration/reference_architectures/50k_users.md
@@ -1058,7 +1058,7 @@ a node and change its status from primary to replica (and vice versa).
    #redis['master_port'] = 6379
 
    # Set up password authentication for Redis and replicas (use the same password in all nodes).
-   redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
+   redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
    redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
 
    ## Must be the same in every Redis node
diff --git a/doc/architecture/blueprints/ci_pipeline_components/index.md b/doc/architecture/blueprints/ci_pipeline_components/index.md
index 79660dcaac2..667c8d225db 100644
--- a/doc/architecture/blueprints/ci_pipeline_components/index.md
+++ b/doc/architecture/blueprints/ci_pipeline_components/index.md
@@ -106,7 +106,7 @@ identifying abstract concepts and are subject to changes as we refine the design
 
 A pipeline component is a reusable single-purpose building block that abstracts away a single pipeline configuration unit.
 Components are used to compose a part or entire pipeline configuration.
-It can optionally take input parameters and set output data to be adaptable and reusable in different pipeline contexts,
+It can optionally take input parameters to be adaptable and reusable in different pipeline contexts,
 while encapsulating and isolating implementation details.
 
 Components allow a pipeline to be assembled by using abstractions instead of having all the details defined in one place.
@@ -204,7 +204,6 @@ A component YAML file:
 - Must specify its **type** in the filename, which defines how it can be used (raw configuration to be `include`d, child pipeline workflow, job step).
 - Must define its **content** based on the type.
 - Must specify **input parameters** that it accepts. Components should depend on input parameters for dynamic values and not environment variables.
-- Can optionally define **output data** that it returns.
 - Should be **validated statically** (for example: using JSON schema validators).
 
 ```yaml
diff --git a/doc/ci/examples/authenticating-with-hashicorp-vault/img/vault-read-secrets-production.png b/doc/ci/examples/authenticating-with-hashicorp-vault/img/vault-read-secrets-production.png
deleted file mode 100644
index 16c15071dd7..00000000000
--- a/doc/ci/examples/authenticating-with-hashicorp-vault/img/vault-read-secrets-production.png
+++ /dev/null
diff --git a/doc/ci/examples/authenticating-with-hashicorp-vault/img/vault-read-secrets-staging.png b/doc/ci/examples/authenticating-with-hashicorp-vault/img/vault-read-secrets-staging.png
deleted file mode 100644
index 7a92a3c2d50..00000000000
--- a/doc/ci/examples/authenticating-with-hashicorp-vault/img/vault-read-secrets-staging.png
+++ /dev/null
diff --git a/doc/ci/index.md b/doc/ci/index.md
index 65e6394b439..75e668290c8 100644
--- a/doc/ci/index.md
+++ b/doc/ci/index.md
@@ -82,8 +82,6 @@ GitLab CI/CD features, grouped by DevOps stage, include:
 | [ChatOps](chatops/index.md)                                                                  | Trigger CI jobs from chat, with results sent back to the channel. |
 | [Connect to cloud services](cloud_services/index.md)                                         | Connect to cloud providers using OpenID Connect (OIDC) to retrieve temporary credentials to access services or secrets. |
 | **Verify**                                                                                   |             |
-| [Browser Performance Testing](testing/browser_performance_testing.md)                        | Quickly determine the browser performance impact of pending code changes. |
-| [Load Performance Testing](testing/load_performance_testing.md)                              | Quickly determine the server performance impact of pending code changes. |
 | [CI services](services/index.md)                                                             | Link Docker containers with your base image. |
 | [GitLab CI/CD for external repositories](ci_cd_for_external_repos/index.md)                  | Get the benefits of GitLab CI/CD combined with repositories in GitHub and Bitbucket Cloud. |
 | [Interactive Web Terminals](interactive_web_terminal/index.md)                               | Open an interactive web terminal to debug the running jobs. |
diff --git a/doc/integration/google.md b/doc/integration/google.md
index e9c52bc3e95..1c027921e4d 100644
--- a/doc/integration/google.md
+++ b/doc/integration/google.md
@@ -9,28 +9,34 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 To enable the Google OAuth 2.0 OmniAuth provider you must register your application
 with Google. Google generates a client ID and secret key for you to use.
 
-## Enable Google OAuth
-
-In Google's side:
-
-1. Navigate to the [cloud resource manager](https://console.cloud.google.com/cloud-resource-manager) page
-1. Select **Create Project**
-1. Provide the project information:
-   - **Project name** - "GitLab" works just fine here.
-   - **Project ID** - Must be unique to all Google Developer registered applications.
-     Google provides a randomly generated Project ID by default. You can use
-     the randomly generated ID or choose a new one.
-1. Refresh the page and you should see your new project in the list
-1. Go to the [Google API Console](https://console.developers.google.com/apis/dashboard)
-1. In the upper-left corner, select the previously created project
-1. Select **OAuth consent screen** from the sidebar and fill the form with the required information
-1. Select **Credentials** from the sidebar, then select **Create credentials > OAuth client ID**
-1. Fill in the required information:
-   - **Application type** - Choose "Web Application"
-   - **Name** - Use the default one or provide your own
-   - **Authorized JavaScript origins** -This isn't really used by GitLab but go
-     ahead and put `https://gitlab.example.com`
-   - **Authorized redirect URIs** - Enter your domain name followed by the
+To enable Google OAuth, you must configure the:
+
+- Google Cloud Resource Manager
+- Google API Console
+- GitLab server
+
+## Configure the Google Cloud Resource Manager
+
+1. Go to the [Google Cloud Resource Manager](https://console.cloud.google.com/cloud-resource-manager).
+1. Select **CREATE PROJECT**.
+1. In **Project name**, enter `GitLab`.
+1. In **Project ID**, Google provides a randomly generated project ID by default.
+   You can use this randomly generated ID or create a new one. If you create a new
+   ID, it must be unique to all Google Developer registered applications.
+
+To see your new project in the list, refresh the page.
+
+## Configure the Google API Console
+
+1. Go to the [Google API Console](https://console.developers.google.com/apis/dashboard).
+1. In the upper-left corner, select your previously created project.
+1. Select **OAuth consent screen** and complete the fields.
+1. Select **Credentials > Create credentials > OAuth client ID**.
+1. Complete the fields:
+   - **Application type**: Select **Web application**.
+   - **Name**: Use the default name or enter your own.
+   - **Authorized JavaScript origins**: Enter `https://gitlab.example.com`.
+   - **Authorized redirect URIs**: Enter your domain name followed by the
      callback URIs one at a time:
 
      ```plaintext
@@ -38,22 +44,22 @@ In Google's side:
      https://gitlab.example.com/-/google_api/auth/callback
      ```
 
-1. You should now be able to see a Client ID and Client secret. Note them down
+1. You should see a client ID and client secret. Note them down
    or keep this page open as you need them later.
-1. To enable projects to access [Google Kubernetes Engine](../user/infrastructure/clusters/index.md), you must also
-   enable these APIs:
+1. To enable projects to access [Google Kubernetes Engine](../user/infrastructure/clusters/index.md),
+   you must also enable the:
    - Google Kubernetes Engine API
    - Cloud Resource Manager API
    - Cloud Billing API
 
-   To do so you should:
+   To do so:
 
    1. Go to the [Google API Console](https://console.developers.google.com/apis/dashboard).
    1. Select **ENABLE APIS AND SERVICES** at the top of the page.
    1. Find each of the above APIs. On the page for the API, select **ENABLE**.
       It may take a few minutes for the API to be fully functional.
 
-On your GitLab server:
+## Configure the GitLab server
 
 1. Open the configuration file.
 
@@ -82,8 +88,8 @@ On your GitLab server:
      {
        name: "google_oauth2",
        # label: "Provider name", # optional label for login button, defaults to "Google"
-       app_id: "YOUR_APP_ID",
-       app_secret: "YOUR_APP_SECRET",
+       app_id: "<YOUR_APP_ID>",
+       app_secret: "<YOUR_APP_SECRET>",
        args: { access_type: "offline", approval_prompt: "" }
      }
    ]
@@ -99,8 +105,8 @@ On your GitLab server:
        args: { access_type: 'offline', approval_prompt: '' } }
    ```
 
-1. Change `YOUR_APP_ID` to the client ID from the Google Developer page
-1. Similarly, change `YOUR_APP_SECRET` to the client secret
+1. Replace `<YOUR_APP_ID>` with the client ID from the Google Developer page.
+1. Replace `<YOUR_APP_SECRET>` with the client secret from the Google Developer page.
 1. Make sure that you configure GitLab to use a fully-qualified domain name, as
    Google doesn't accept raw IP addresses.
 
diff --git a/doc/operations/img/error_details_v12_7.png b/doc/operations/img/error_details_v12_7.png
deleted file mode 100644
index 05070ce06b9..00000000000
--- a/doc/operations/img/error_details_v12_7.png
+++ /dev/null
diff --git a/doc/operations/img/error_tracking_list_v12_6.png b/doc/operations/img/error_tracking_list_v12_6.png
deleted file mode 100644
index af57691b14a..00000000000
--- a/doc/operations/img/error_tracking_list_v12_6.png
+++ /dev/null
diff --git a/doc/tutorials/configure_gitlab_runner_to_use_gke/index.md b/doc/tutorials/configure_gitlab_runner_to_use_gke/index.md
index bf8f25081c4..21570f0669e 100644
--- a/doc/tutorials/configure_gitlab_runner_to_use_gke/index.md
+++ b/doc/tutorials/configure_gitlab_runner_to_use_gke/index.md
@@ -4,7 +4,7 @@ group: Runner
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Tutorial: Configure GitLab Runner to use the Google Kubernetes Engine
+# Tutorial: Configure GitLab Runner to use the Google Kubernetes Engine **(FREE)**
 
 This tutorial describes how to configure GitLab Runner to use the Google Kubernetes Engine (GKE)
 to run jobs.
@@ -187,12 +187,12 @@ To check if runners are running in the GKE cluster, you can either:
   kubectl get pods
   ```
 
-  You should see the following output, which shows your runners
+  You should see the following output. This shows that your runners
   are running in the GKE cluster:
 
   ```plaintext
   NAME                             READY   STATUS    RESTARTS   AGE
-  gitlab-runner-bf9894bdb-wplxn    1/1     Running   0          5m
+  gitlab-runner-hash-short_hash    1/1     Running   0          5m
   ```
 
 - Check the job log in GitLab:
diff --git a/doc/user/application_security/secret_detection/img/secret_detection_v13_2.png b/doc/user/application_security/secret_detection/img/secret_detection_v13_2.png
deleted file mode 100644
index 4aa7dd83c8d..00000000000
--- a/doc/user/application_security/secret_detection/img/secret_detection_v13_2.png
+++ /dev/null
diff --git a/doc/user/clusters/img/kubecost_v13_5.png b/doc/user/clusters/img/kubecost_v13_5.png
deleted file mode 100644
index a93e2531b16..00000000000
--- a/doc/user/clusters/img/kubecost_v13_5.png
+++ /dev/null
diff --git a/doc/user/project/integrations/img/merge_request_performance.png b/doc/user/project/integrations/img/merge_request_performance.png
deleted file mode 100644
index a9cd761cdcb..00000000000
--- a/doc/user/project/integrations/img/merge_request_performance.png
+++ /dev/null
diff --git a/doc/user/project/integrations/img/prometheus_dashboard.png b/doc/user/project/integrations/img/prometheus_dashboard.png
deleted file mode 100644
index 24d855eb50c..00000000000
--- a/doc/user/project/integrations/img/prometheus_dashboard.png
+++ /dev/null
diff --git a/doc/user/project/integrations/img/prometheus_manual_configuration_v13_2.png b/doc/user/project/integrations/img/prometheus_manual_configuration_v13_2.png
deleted file mode 100644
index b6ec08f492d..00000000000
--- a/doc/user/project/integrations/img/prometheus_manual_configuration_v13_2.png
+++ /dev/null