summaryrefslogtreecommitdiff
path: root/doc/update
diff options
context:
space:
mode:
authorGitLab Bot <gitlab-bot@gitlab.com>2022-07-20 15:40:28 +0000
committerGitLab Bot <gitlab-bot@gitlab.com>2022-07-20 15:40:28 +0000
commitb595cb0c1dec83de5bdee18284abe86614bed33b (patch)
tree8c3d4540f193c5ff98019352f554e921b3a41a72 /doc/update
parent2f9104a328fc8a4bddeaa4627b595166d24671d0 (diff)
downloadgitlab-ce-b595cb0c1dec83de5bdee18284abe86614bed33b.tar.gz
Add latest changes from gitlab-org/gitlab@15-2-stable-eev15.2.0-rc42
Diffstat (limited to 'doc/update')
-rw-r--r--doc/update/deprecations.md42
-rw-r--r--doc/update/index.md60
-rw-r--r--doc/update/package/convert_to_ee.md26
-rw-r--r--doc/update/package/downgrade.md2
-rw-r--r--doc/update/package/index.md7
-rw-r--r--doc/update/patch_versions.md6
-rw-r--r--doc/update/plan_your_upgrade.md4
-rw-r--r--doc/update/removals.md72
-rw-r--r--doc/update/upgrading_from_ce_to_ee.md6
-rw-r--r--doc/update/upgrading_from_source.md19
-rw-r--r--doc/update/with_downtime.md20
-rw-r--r--doc/update/zero_downtime.md30
12 files changed, 212 insertions, 82 deletions
diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index d726f96f646..81b98b95068 100644
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@@ -45,6 +45,27 @@ sole discretion of GitLab Inc.
<div class="announcement-milestone">
+## Announced in 15.2
+
+<div class="deprecation removal-160 breaking-change">
+
+### Remove `job_age` parameter from `POST /jobs/request` Runner endpoint
+
+Planned removal: GitLab <span class="removal-milestone">16.0</span> (2023-05-22)
+
+WARNING:
+This is a [breaking change](https://docs.gitlab.com/ee/development/contributing/#breaking-changes).
+Review the details carefully before upgrading.
+
+The `job_age` parameter, returned from the `POST /jobs/request` API endpoint used in communication with GitLab Runner, was never used by any GitLab or Runner feature. This parameter will be removed in GitLab 16.0.
+
+This could be a breaking change for anyone that developed their own runner that relies on this parameter being returned by the endpoint. This is not a breaking change for anyone using an officially released version of GitLab Runner, including public shared runners on GitLab.com.
+
+</div>
+</div>
+
+<div class="announcement-milestone">
+
## Announced in 15.1
<div class="deprecation removal-160 breaking-change">
@@ -892,11 +913,11 @@ If you have explicitly excluded retire.js using DS_EXCLUDED_ANALYZERS you will n
</div>
-<div class="deprecation removal-152 breaking-change">
+<div class="deprecation removal-154 breaking-change">
### SAST analyzer consolidation and CI/CD template changes
-Planned removal: GitLab <span class="removal-milestone">15.2</span> (2022-07-22)
+Planned removal: GitLab <span class="removal-milestone">15.4</span> (2022-09-22)
WARNING:
This is a [breaking change](https://docs.gitlab.com/ee/development/contributing/#breaking-changes).
@@ -905,9 +926,9 @@ Review the details carefully before upgrading.
GitLab SAST uses various [analyzers](https://docs.gitlab.com/ee/user/application_security/sast/analyzers/) to scan code for vulnerabilities.
We are reducing the number of analyzers used in GitLab SAST as part of our long-term strategy to deliver a better and more consistent user experience.
-Streamlining the set of analyzers will also enable faster [iteration](https://about.gitlab.com/handbook/values/#iteration), better [results](https://about.gitlab.com/handbook/values/#results), and greater [efficiency](https://about.gitlab.com/handbook/values/#results) (including a reduction in CI runner usage in most cases).
+Streamlining the set of analyzers will also enable faster [iteration](https://about.gitlab.com/handbook/values/#iteration), better [results](https://about.gitlab.com/handbook/values/#results), and greater [efficiency](https://about.gitlab.com/handbook/values/#efficiency) (including a reduction in CI runner usage in most cases).
-In GitLab 15.2, GitLab SAST will no longer use the following analyzers:
+In GitLab 15.4, GitLab SAST will no longer use the following analyzers:
- [ESLint](https://gitlab.com/gitlab-org/security-products/analyzers/eslint) (JavaScript, TypeScript, React)
- [Gosec](https://gitlab.com/gitlab-org/security-products/analyzers/gosec) (Go)
@@ -922,7 +943,14 @@ We will not delete container images previously published for these analyzers; an
We will also remove Java from the scope of the [SpotBugs](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs) analyzer and replace it with the [Semgrep-based analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep).
This change will make it simpler to scan Java code; compilation will no longer be required.
-This change will be reflected in the automatic language detection portion of the [GitLab-managed SAST CI/CD template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml).
+This change will be reflected in the automatic language detection portion of the [GitLab-managed SAST CI/CD template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml). Note that the SpotBugs-based analyzer will continue to cover Groovy, Kotlin, and Scala.
+
+If you've already dismissed a vulnerability finding from one of the deprecated analyzers, the replacement attempts to respect your previous dismissal. The system behavior depends on:
+
+- whether you’ve excluded the Semgrep-based analyzer from running in the past.
+- which analyzer first discovered the vulnerabilities shown in the project’s Vulnerability Report.
+
+See [Vulnerability translation documentation](https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html#vulnerability-translation) for further details.
If you applied customizations to any of the affected analyzers or if you currently disable the Semgrep analyzer in your pipelines, you must take action as detailed in the [deprecation issue for this change](https://gitlab.com/gitlab-org/gitlab/-/issues/352554#breaking-change).
@@ -1453,12 +1481,12 @@ Tracing in GitLab is an integration with Jaeger, an open-source end-to-end distr
<div class="deprecation removal-150">
-### `artifacts:report:cobertura` keyword
+### `artifacts:reports:cobertura` keyword
Planned removal: GitLab <span class="removal-milestone">15.0</span> (2022-05-22)
Currently, test coverage visualizations in GitLab only support Cobertura reports. Starting 15.0, the
-`artifacts:report:cobertura` keyword will be replaced by
+`artifacts:reports:cobertura` keyword will be replaced by
[`artifacts:reports:coverage_report`](https://gitlab.com/gitlab-org/gitlab/-/issues/344533). Cobertura will be the
only supported report file in 15.0, but this is the first step towards GitLab supporting other report types.
diff --git a/doc/update/index.md b/doc/update/index.md
index dcdcf8f01ae..e9fa2321450 100644
--- a/doc/update/index.md
+++ b/doc/update/index.md
@@ -54,7 +54,7 @@ There are also instructions when you want to
Editions.
In the past we used separate documents for the upgrading instructions, but we
-have since switched to using a single document. The old upgrading guidelines
+have switched to using a single document. The old upgrading guidelines
can still be found in the Git repository:
- [Old upgrading guidelines for Community Edition](https://gitlab.com/gitlab-org/gitlab-foss/tree/11-8-stable/doc/update)
@@ -63,8 +63,8 @@ can still be found in the Git repository:
### Installation using Docker
GitLab provides official Docker images for both Community and Enterprise
-editions. They are based on the Omnibus package and instructions on how to
-update them are in [a separate document](https://docs.gitlab.com/omnibus/docker/README.html).
+editions, and they are based on the Omnibus package. See how to
+[install GitLab using Docker](../install/docker.md).
### Installation using Helm
@@ -179,7 +179,7 @@ Expected batched background migration for the given configuration to be marked a
If you get this error, [check the batched background migration options](../user/admin_area/monitoring/background_migrations.md#database-migrations-failing-because-of-batched-background-migration-not-finished) to complete the upgrade.
-### What do I do if my background migrations are stuck?
+### What do you do if your background migrations are stuck?
WARNING:
The following operations can disrupt your GitLab performance. They run a number of Sidekiq jobs that perform various database or file updates.
@@ -331,11 +331,11 @@ cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:elastic:list_pending_migrations
```
-### What do I do if my Advanced Search migrations are stuck?
+### What do you do if your Advanced Search migrations are stuck?
See [how to retry a halted migration](../integration/advanced_search/elasticsearch.md#retry-a-halted-migration).
-### What do I do for the error `Elasticsearch version not compatible`
+### What do you do for the error `Elasticsearch version not compatible`
Confirm that your version of Elasticsearch or OpenSearch is [compatible with your version of GitLab](../integration/advanced_search/elasticsearch.md#version-requirements).
@@ -361,7 +361,7 @@ It's also important to ensure that any [background migrations have been fully co
before upgrading to a new major version.
If you have enabled the [Elasticsearch integration](../integration/advanced_search/elasticsearch.md) **(PREMIUM SELF)**, then
-[ensure all Advanced Search migrations are completed](#checking-for-pending-advanced-search-migrations) in the last minor version within
+[ensure all Advanced Search migrations are completed](#checking-for-pending-advanced-search-migrations) in the last minor version in
your current version
before proceeding with the major version upgrade.
@@ -379,7 +379,7 @@ Find where your version sits in the upgrade path below, and upgrade GitLab
accordingly, while also consulting the
[version-specific upgrade instructions](#version-specific-upgrading-instructions):
-`8.11.Z` -> `8.12.0` -> `8.17.7` -> `9.5.10` -> `10.8.7` -> [`11.11.8`](#1200) -> `12.0.12` -> [`12.1.17`](#1210) -> [`12.10.14`](#12100) -> `13.0.14` -> [`13.1.11`](#1310) -> [`13.8.8`](#1388) -> [`13.12.15`](#13120) -> [`14.0.12`](#1400) -> [`14.3.6`](#1430) -> [`14.9.5`](#1490) -> [`14.10.Z`](#1410) -> [`15.0.Z`](#1500) -> [latest `15.Y.Z`](https://gitlab.com/gitlab-org/gitlab/-/releases)
+`8.11.Z` -> `8.12.0` -> `8.17.7` -> `9.5.10` -> `10.8.7` -> [`11.11.8`](#1200) -> `12.0.12` -> [`12.1.17`](#1210) -> [`12.10.14`](#12100) -> `13.0.14` -> [`13.1.11`](#1310) -> [`13.8.8`](#1388) -> [`13.12.15`](#13120) -> [`14.0.12`](#1400) -> [`14.3.6`](#1430) -> [`14.9.5`](#1490) -> [`14.10.Z`](#14100) -> [`15.0.Z`](#1500) -> [latest `15.Y.Z`](https://gitlab.com/gitlab-org/gitlab/-/releases)
The following table, while not exhaustive, shows some examples of the supported
upgrade paths.
@@ -387,8 +387,8 @@ Additional steps between the mentioned versions are possible. We list the minima
| Target version | Your version | Supported upgrade path | Note |
| -------------- | ------------ | ---------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
-| `15.1.0` | `14.6.2` | `14.6.2` -> `14.9.5` -> `14.10.4` -> `15.0.2` -> `15.1.0` | Three intermediate versions are required: `14.9` and `14.10`, `15.0`, then `15.1.0`. |
-| `15.0.0` | `14.6.2` | `14.6.2` -> `14.9.5` -> `14.10.4` -> `15.0.2` | Two intermediate versions are required: `14.9` and `14.10`, then `15.0.0`. |
+| `15.1.0` | `14.6.2` | `14.6.2` -> `14.9.5` -> `14.10.5` -> `15.0.2` -> `15.1.0` | Three intermediate versions are required: `14.9` and `14.10`, `15.0`, then `15.1.0`. |
+| `15.0.0` | `14.6.2` | `14.6.2` -> `14.9.5` -> `14.10.5` -> `15.0.2` | Two intermediate versions are required: `14.9` and `14.10`, then `15.0.0`. |
| `14.6.2` | `13.10.2` | `13.10.2` -> `13.12.15` -> `14.0.12` -> `14.3.6` => `14.6.2` | Three intermediate versions are required: `13.12` and `14.0`, `14.3`, then `14.6.2`. |
| `14.1.8` | `13.9.2` | `13.9.2` -> `13.12.15` -> `14.0.12` -> `14.1.8` | Two intermediate versions are required: `13.12` and `14.0`, then `14.1.8`. |
| `13.12.15` | `12.9.2` | `12.9.2` -> `12.10.14` -> `13.0.14` -> `13.1.11` -> `13.8.8` -> `13.12.15` | Four intermediate versions are required: `12.10`, `13.0`, `13.1` and `13.8.8`, then `13.12.15`. |
@@ -425,7 +425,7 @@ Edition, follow the guides below based on the installation method:
### Enterprise to Community Edition
-If you need to downgrade your Enterprise Edition installation back to Community
+To downgrade your Enterprise Edition installation back to Community
Edition, you can follow [this guide](../downgrade_ee_to_ce/index.md) to make the process as smooth as
possible.
@@ -442,7 +442,7 @@ At the end of major and minor release posts, there are three sections to look fo
These include:
-- Steps you need to perform as part of an upgrade.
+- Steps you must perform as part of an upgrade.
For example [8.12](https://about.gitlab.com/releases/2016/09/22/gitlab-8-12-released/#upgrade-barometer)
required the Elasticsearch index to be recreated. Any older version of GitLab upgrading to 8.12 or later would require this.
- Changes to the versions of software we support such as
@@ -458,11 +458,28 @@ NOTE:
Specific information that follow related to Ruby and Git versions do not apply to [Omnibus installations](https://docs.gitlab.com/omnibus/)
and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with appropriate Ruby and Git versions and are not using system binaries for Ruby and Git. There is no need to install Ruby or Git when utilizing these two approaches.
+### 15.2.0 (unreleased)
+
+- GitLab installations that have multiple web nodes should be
+ [upgraded to 15.1](#1510) before upgrading to 15.2 (and later) due to a
+ configuration change in Rails that can result in inconsistent ETag key
+ generation.
+- Some Sidekiq workers were renamed in this release. To avoid any disruption, [run the Rake tasks to migrate any pending jobs](../raketasks/sidekiq_job_migration.md#future-jobs) before starting the upgrade to GitLab 15.2.0.
+
### 15.1.0
- If you run external PostgreSQL, particularly AWS RDS,
[check you have a PostgreSQL bug fix](#postgresql-segmentation-fault-issue)
to avoid the database crashing.
+- In GitLab 15.1.0, we are switching Rails `ActiveSupport::Digest` to use SHA256 instead of MD5.
+ This affects ETag key generation for resources such as raw Snippet file
+ downloads. To ensure consistent ETag key generation across multiple
+ web nodes when upgrading, all servers must first be upgraded to 15.1.Z before
+ upgrading to 15.2.0 or later:
+
+ 1. Ensure all GitLab web nodes are running GitLab 15.1.Z.
+ 1. [Enable the `active_support_hash_digest_sha256` feature flag](../administration/feature_flags.md#how-to-enable-and-disable-features-behind-flags) to switch `ActiveSupport::Digest` to use SHA256:
+ 1. Only then, continue to upgrade to later versions of GitLab.
- Unauthenticated requests to the [`ciConfig` GraphQL field](../api/graphql/reference/index.md#queryciconfig) are no longer supported.
Before you upgrade to GitLab 15.1, add an [access token](../api/index.md#authentication) to your requests.
The user creating the token must have [permission](../user/permissions.md) to create pipelines in the project.
@@ -473,6 +490,9 @@ and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with ap
- If you run external PostgreSQL, particularly AWS RDS,
[check you have a PostgreSQL bug fix](#postgresql-segmentation-fault-issue)
to avoid the database crashing.
+- The use of encrypted S3 buckets with storage-specific configuration is no longer supported after [removing support for using `background_upload`](removals.md#background-upload-for-object-storage).
+- The [certificate-based Kubernetes integration (DEPRECATED)](../user/infrastructure/clusters/index.md#certificate-based-kubernetes-integration-deprecated) is disabled by default, but you can be re-enable it through the [`certificate_based_clusters` feature flag](../administration/feature_flags.md#how-to-enable-and-disable-features-behind-flags) until GitLab 16.0.
+- When you use the GitLab Helm Chart project with a custom `serviceAccount`, ensure it has `get` and `list` permissions for the `serviceAccount` and `secret` resources.
### 14.10.0
@@ -634,7 +654,7 @@ or [init scripts](upgrading_from_source.md#configure-sysv-init-script) by [follo
All merge request diff commits automatically incorporate these changes, and there are no
additional requirements to perform the upgrade.
Existing data in the `merge_request_diff_commits` table remains unpacked until you run `VACUUM FULL merge_request_diff_commits`.
- But note that the `VACUUM FULL` operation locks and rewrites the entire `merge_request_diff_commits` table,
+ However, the `VACUUM FULL` operation locks and rewrites the entire `merge_request_diff_commits` table,
so the operation takes some time to complete and it blocks access to this table until the end of the process.
We advise you to only run this command while GitLab is not actively used or it is taken offline for the duration of the process.
The time it takes to complete depends on the size of the table, which can be obtained by using `select pg_size_pretty(pg_total_relation_size('merge_request_diff_commits'));`.
@@ -684,6 +704,10 @@ or [init scripts](upgrading_from_source.md#configure-sysv-init-script) by [follo
as Sidekiq would continue using a bad connection. Geo and other features that rely on
cron jobs running regularly do not work until Sidekiq is restarted. We recommend
upgrading to GitLab 14.4.3 and later if this issue affects you.
+- After enabling database load balancing by default in 14.4.0, we found an issue where
+ [Database load balancing does not work with an AWS Aurora cluster](https://gitlab.com/gitlab-org/gitlab/-/issues/220617).
+ We recommend moving your databases from Aurora to RDS for PostgreSQL before
+ upgrading. Refer to [Moving GitLab databases to a different PostgreSQL instance](../administration/postgresql/moving.md).
- GitLab 14.4.0 includes a
[background migration `PopulateTopicsTotalProjectsCountCache`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/71033)
that may remain stuck permanently in a **pending** state when the instance lacks records that match the migration's target.
@@ -750,7 +774,7 @@ for how to proceed.
- [`geo_job_artifact_deleted_events`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66763)
- [`push_event_payloads`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67299)
- `ci_job_artifacts`:
- - [Finalize job_id conversion to `bigint` for `ci_job_artifacts`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67774)
+ - [Finalize `job_id` conversion to `bigint` for `ci_job_artifacts`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67774)
- [Finalize `ci_job_artifacts` conversion to `bigint`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/65601)
If the migrations are executed as part of a no-downtime deployment, there's a risk of failure due to lock conflicts with the application logic, resulting in lock timeout or deadlocks. In each case, these migrations are safe to re-run until successful:
@@ -992,10 +1016,10 @@ GitLab 13.2.0 [remediates](https://gitlab.com/gitlab-org/gitlab/-/merge_requests
After upgrading, if some of your users are unexpectedly encountering 404 or 422 errors when signing in,
or "blocked" messages when using the command line,
their accounts may have been un-confirmed.
-In that case, please ask them to check their email for a re-confirmation link.
+In that case, ask them to check their email for a re-confirmation link.
For more information, see our discussion of [Email confirmation issues](../user/upgrade_email_bypass.md).
-GitLab 13.2.0 relies on the `btree_gist` extension for PostgreSQL. For installations with an externally managed PostgreSQL setup, please make sure to
+GitLab 13.2.0 relies on the `btree_gist` extension for PostgreSQL. For installations with an externally managed PostgreSQL setup, make sure to
[install the extension manually](https://www.postgresql.org/docs/11/sql-createextension.html) before upgrading GitLab if the database user for GitLab
is not a superuser. This is not necessary for installations using a GitLab managed PostgreSQL database.
@@ -1042,7 +1066,7 @@ If you persist your own Rack Attack initializers between upgrades, you might
- The final patch release (12.10.14)
[has a regression affecting maven package uploads](https://about.gitlab.com/releases/2020/07/06/critical-security-release-gitlab-13-1-3-released/#maven-package-upload-broken-in-121014).
- If you use this feature and need to stay on 12.10 while preparing to upgrade to 13.0:
+ If you use this feature and must stay on 12.10 while preparing to upgrade to 13.0:
- Upgrade to 12.10.13 instead.
- Upgrade to 13.0.14 as soon as possible.
@@ -1103,7 +1127,7 @@ When Geo is enabled, LFS objects fail to be saved for imported or mirrored proje
### PostgreSQL segmentation fault issue
If you run GitLab with external PostgreSQL, particularly AWS RDS, ensure you upgrade PostgreSQL
-to patch levels to a minimum of 12.10 or 13.3 before upgrading to GitLab 14.8 or later.
+to patch levels to a minimum of 12.7 or 13.3 before upgrading to GitLab 14.8 or later.
[In 14.8](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/75511)
for GitLab Enterprise Edition and [in 15.1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/87983)
diff --git a/doc/update/package/convert_to_ee.md b/doc/update/package/convert_to_ee.md
index 34bd8e61107..9f8e56c460c 100644
--- a/doc/update/package/convert_to_ee.md
+++ b/doc/update/package/convert_to_ee.md
@@ -15,7 +15,7 @@ Converting from the same version of CE to EE is not explicitly necessary, and an
you are upgrading the same version (for example, CE 12.1 to EE 12.1), which is **recommended**.
WARNING:
-When updating to EE from CE, avoid reverting back to CE if you plan on going to EE again in the
+When updating to EE from CE, avoid reverting back to CE if you plan to go to EE again in the
future. Reverting back to CE can cause
[database issues](index.md#500-error-when-accessing-project--settings--repository)
that may require Support intervention.
@@ -31,7 +31,7 @@ The steps can be summed up to:
```
The output should be similar to: `Installed: 13.0.4-ce.0`. In that case,
- the equivalent Enterprise Edition version will be: `13.0.4-ee.0`. Write this
+ the equivalent Enterprise Edition version is: `13.0.4-ee.0`. Write this
value down.
**For CentOS/RHEL**
@@ -41,7 +41,7 @@ The steps can be summed up to:
```
The output should be similar to: `gitlab-ce-13.0.4-ce.0.el8.x86_64`. In that
- case, the equivalent Enterprise Edition version will be:
+ case, the equivalent Enterprise Edition version is:
`gitlab-ee-13.0.4-ee.0.el8.x86_64`. Write this value down.
1. Add the `gitlab-ee` [Apt or Yum repository](https://packages.gitlab.com/gitlab/gitlab-ee/install):
@@ -58,13 +58,19 @@ The steps can be summed up to:
curl --silent "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh" | sudo bash
```
- The above command will find your OS version and automatically set up the
+ The above command finds your OS version and automatically set up the
repository. If you are not comfortable installing the repository through a
piped script, you can first
[check its contents](https://packages.gitlab.com/gitlab/gitlab-ee/install).
-1. Next, install the `gitlab-ee` package. Note that this will automatically
- uninstall the `gitlab-ce` package on your GitLab server. `reconfigure`
+ NOTE:
+ If you want to use `dpkg`/`rpm` instead of `apt-get`/`yum`, go through the first
+ step to find the current GitLab version, then follow
+ [Update using a manually-downloaded package](index.md#upgrade-using-a-manually-downloaded-package),
+ and then [add your license](../../user/admin_area/license.md).
+
+1. Install the `gitlab-ee` package. The install automatically
+ uninstalls the `gitlab-ce` package on your GitLab server. `reconfigure`
Omnibus right after the `gitlab-ee` package is installed. **Make sure that you
install the exact same GitLab version**:
@@ -91,8 +97,7 @@ The steps can be summed up to:
sudo gitlab-ctl reconfigure
```
-1. Now go to the GitLab Admin Area of your server (`/admin/subscription`) and
- [add your license](../../user/admin_area/license.md).
+1. Now activate GitLab Enterprise Edition by [adding your license](../../user/admin_area/license.md).
1. After you confirm that GitLab is working as expected, you may remove the old
Community Edition repository:
@@ -111,8 +116,3 @@ The steps can be summed up to:
That's it! You can now use GitLab Enterprise Edition! To update to a newer
version, follow [Update using the official repositories](index.md#upgrade-using-the-official-repositories).
-
-NOTE:
-If you want to use `dpkg`/`rpm` instead of `apt-get`/`yum`, go through the first
-step to find the current GitLab version and then follow
-[Update using a manually-downloaded package](index.md#upgrade-using-a-manually-downloaded-package).
diff --git a/doc/update/package/downgrade.md b/doc/update/package/downgrade.md
index 7b8b4da0383..f48ba31568f 100644
--- a/doc/update/package/downgrade.md
+++ b/doc/update/package/downgrade.md
@@ -79,5 +79,5 @@ Steps:
sudo gitlab-ctl reconfigure
```
-1. [Restore GitLab](../../raketasks/backup_restore.md#restore-for-omnibus-gitlab-installations)
+1. [Restore GitLab](../../raketasks/restore_gitlab.md#restore-for-omnibus-gitlab-installations)
to complete the downgrade.
diff --git a/doc/update/package/index.md b/doc/update/package/index.md
index 15f43f59425..bf1154d1cf5 100644
--- a/doc/update/package/index.md
+++ b/doc/update/package/index.md
@@ -189,6 +189,11 @@ NOTE:
For the GitLab Community Edition, replace `gitlab-ee` with
`gitlab-ce`.
+## Upgrade the product documentation
+
+This is an optional step. If you [installed the product documentation](../../administration/docs_self_host.md),
+see how to [upgrade to a later version](../../administration/docs_self_host.md#upgrade-using-docker).
+
## Troubleshooting
### GitLab 13.7 and later unavailable on Amazon Linux 2
@@ -300,7 +305,7 @@ To fix this issue:
### Error `Failed to connect to the internal GitLab API` on a separate GitLab Pages server
-Please see [GitLab Pages troubleshooting](../../administration/pages/index.md#failed-to-connect-to-the-internal-gitlab-api).
+See [GitLab Pages troubleshooting](../../administration/pages/index.md#failed-to-connect-to-the-internal-gitlab-api).
### Error `An error occurred during the signature verification` when running `apt-get update`
diff --git a/doc/update/patch_versions.md b/doc/update/patch_versions.md
index dc09f6063c8..b7c148045bd 100644
--- a/doc/update/patch_versions.md
+++ b/doc/update/patch_versions.md
@@ -11,11 +11,11 @@ comments: false
Make sure you view [this update guide](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/update/patch_versions.md) from the tag (version) of GitLab you would like to install.
In most cases this should be the highest numbered production tag (without `rc` in it).
-You can select the tag in the version dropdown in the top left corner of GitLab (below the menu bar).
+You can select the tag in the version dropdown list in the top left corner of GitLab (below the menu bar).
### 0. Backup
-It's useful to make a backup just in case things go south. Depending on the installation method, backup commands vary. See the [backing up and restoring GitLab](../raketasks/backup_restore.md) documentation.
+Make a backup just in case things go south. Depending on the installation method, backup commands vary. See the [backing up and restoring GitLab](../raketasks/backup_restore.md) documentation.
### 1. Stop server
@@ -107,7 +107,7 @@ sudo -u git -H make
### 8. Install/Update `gitlab-elasticsearch-indexer` **(PREMIUM SELF)**
-Please follow the [install instruction](../integration/advanced_search/elasticsearch.md#install-elasticsearch).
+Follow the [install instruction](../integration/advanced_search/elasticsearch.md#install-elasticsearch).
### 9. Start application
diff --git a/doc/update/plan_your_upgrade.md b/doc/update/plan_your_upgrade.md
index cdc3ec39f9a..2374856ff0c 100644
--- a/doc/update/plan_your_upgrade.md
+++ b/doc/update/plan_your_upgrade.md
@@ -87,7 +87,7 @@ to roll back GitLab to a working state if there's a problem with the upgrade:
- Create a [GitLab backup](../raketasks/backup_restore.md).
Make sure to follow the instructions based on your installation method.
- Don't forget to back up the [secrets and configuration files](../raketasks/backup_restore.md#storing-configuration-files).
+ Don't forget to back up the [secrets and configuration files](../raketasks/backup_gitlab.md#storing-configuration-files).
- Alternatively, create a snapshot of your instance. If this is a multi-node
installation, you must snapshot every node.
**This process is out of scope for GitLab Support.**
@@ -103,7 +103,7 @@ To restore your GitLab backup:
the versions of the backed up and the new GitLab instance must be the same.
- [Restore GitLab](../raketasks/backup_restore.md#restore-gitlab).
Make sure to follow the instructions based on your installation method.
- Confirm that the [secrets and configuration files](../raketasks/backup_restore.md#storing-configuration-files) are also restored.
+ Confirm that the [secrets and configuration files](../raketasks/backup_gitlab.md#storing-configuration-files) are also restored.
- If restoring from a snapshot, know the steps to do this.
**This process is out of scope for GitLab Support.**
diff --git a/doc/update/removals.md b/doc/update/removals.md
index 299d1b4c341..fa5c016d3ab 100644
--- a/doc/update/removals.md
+++ b/doc/update/removals.md
@@ -31,6 +31,25 @@ For removal reviewers (Technical Writers only):
https://about.gitlab.com/handbook/marketing/blog/release-posts/#update-the-removals-doc
-->
+## Removed in 15.2
+
+### Support for older browsers
+
+In GitLab 15.2, we are cleaning up and [removing old code](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86003) that was specific for browsers that we no longer support. This has no impact on users if they use one of our [supported web browsers](https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers).
+
+Most notably, support for the following browsers has been removed:
+
+- Apple Safari 14 and older.
+- Mozilla Firefox 78.
+
+The minimum supported browser versions are:
+
+- Apple Safari 14.1.
+- Mozilla Firefox 91.
+- Google Chrome 92.
+- Chromium 92.
+- Microsoft Edge 92.
+
## Removed in 15.0
### API: `stale` status returned instead of `offline` or `not_connected`
@@ -66,14 +85,45 @@ This is a [breaking change](https://docs.gitlab.com/ee/development/contributing/
Review the details carefully before upgrading.
To reduce the overall complexity and maintenance burden of GitLab's [object storage feature](https://docs.gitlab.com/ee/administration/object_storage.html), support for using `background_upload` has been removed in GitLab 15.0.
+By default [direct upload](https://docs.gitlab.com/ee/development/uploads/index.html#direct-upload) will be used.
-This impacts a small subset of object storage providers, including but not limited to:
+This impacts a subset of object storage providers, including but not limited to:
- **OpenStack** Customers using OpenStack need to change their configuration to use the S3 API instead of Swift.
- **RackSpace** Customers using RackSpace-based object storage need to migrate data to a different provider.
If your object storage provider does not support `background_upload`, please [migrate objects to a supported object storage provider](https://docs.gitlab.com/ee/administration/object_storage.html#migrate-objects-to-a-different-object-storage-provider).
+#### Encrypted S3 buckets
+
+Additionally, this also breaks the use of [encrypted S3 buckets](https://docs.gitlab.com/ee/administration/object_storage.html#encrypted-s3-buckets) with [storage-specific configuration form](https://docs.gitlab.com/ee/administration/object_storage.html#storage-specific-configuration).
+
+If your S3 buckets have [SSE-S3 or SSE-KMS encryption enabled](https://docs.aws.amazon.com/kms/latest/developerguide/services-s3.html), please [migrate your configuration to use consolidated object storage form](https://docs.gitlab.com/ee/administration/object_storage.html#transition-to-consolidated-form) before upgrading to GitLab 15.0. Otherwise, you may start getting `ETag mismatch` errors during objects upload.
+
+#### 403 errors
+
+If you see 403 errors when uploading to object storage after
+upgrading to GitLab 15.0, check that the [correct permissions](https://docs.gitlab.com/ee/administration/object_storage.html#iam-permissions)
+are assigned to the bucket. Direct upload needs the ability to delete an
+object (example: `s3:DeleteObject`), but background uploads do not.
+
+#### `remote_directory` with a path prefix
+
+If the object storage `remote_directory` configuration contains a slash (`/`) after the bucket (example: `gitlab/uploads`), be aware that this [was never officially supported](https://gitlab.com/gitlab-org/gitlab/-/issues/292958).
+Some users found that they could specify a path prefix to the bucket. In direct upload mode, object storage uploads will fail if a slash is present in GitLab 15.0.
+
+If you have set a prefix, you can use a workaround to revert to background uploads:
+
+1. Continue to use [storage-specific configuration](https://docs.gitlab.com/ee/administration/object_storage.html#storage-specific-configuration).
+1. In Omnibus GitLab, set the `GITLAB_LEGACY_BACKGROUND_UPLOADS` to re-enable background uploads:
+
+ ```ruby
+ gitlab_rails['env'] = { 'GITLAB_LEGACY_BACKGROUND_UPLOADS' => 'artifacts,external_diffs,lfs,uploads,packages,dependency_proxy,terraform_state,pages' }
+ ```
+
+Prefixes will be supported officially in [GitLab 15.2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91307).
+This workaround will be dropped, so we encourage migrating to consolidated object storage.
+
### Container Network and Host Security
WARNING:
@@ -443,6 +493,22 @@ You can still customize the behavior of the Secret Detection analyzer using the
For further details, see [the deprecation issue for this change](https://gitlab.com/gitlab-org/gitlab/-/issues/352565).
+### Self-managed certificate-based integration with Kubernetes feature flagged
+
+WARNING:
+This is a [breaking change](https://docs.gitlab.com/ee/development/contributing/#breaking-changes).
+Review the details carefully before upgrading.
+
+In 15.0 the certificate-based integration with Kubernetes will be disabled by default.
+
+After 15.0, you should use the [agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/) to connect Kubernetes clusters with GitLab. The agent for Kubernetes is a more robust, secure, and reliable integration with Kubernetes. [How do I migrate to the agent?](https://docs.gitlab.com/ee/user/infrastructure/clusters/migrate_to_gitlab_agent.html)
+
+If you need more time to migrate, you can enable the `certificate_based_clusters` [feature flag](https://docs.gitlab.com/ee/administration/feature_flags.html), which re-enables the certificate-based integration.
+
+In GitLab 16.0, we will [remove the feature, its related code, and the feature flag](https://about.gitlab.com/blog/2021/11/15/deprecating-the-cert-based-kubernetes-integration/). GitLab will continue to fix any security or critical issues until 16.0.
+
+For updates and details, follow [this epic](https://gitlab.com/groups/gitlab-org/configure/-/epics/8).
+
### Sidekiq configuration for metrics and health checks
WARNING:
@@ -553,9 +619,9 @@ Review the details carefully before upgrading.
The `Managed-Cluster-Applications.gitlab-ci.yml` CI/CD template is being removed. If you need an alternative, try the [Cluster Management project template](https://gitlab.com/gitlab-org/gitlab/-/issues/333610) instead. If your are not ready to move, you can copy the [last released version](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/v14.10.1/lib/gitlab/ci/templates/Managed-Cluster-Applications.gitlab-ci.yml) of the template into your project.
-### `artifacts:report:cobertura` keyword
+### `artifacts:reports:cobertura` keyword
-As of GitLab 15.0, the [`artifacts:report:cobertura`](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportscobertura-removed)
+As of GitLab 15.0, the [`artifacts:reports:cobertura`](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportscobertura-removed)
keyword has been [replaced](https://gitlab.com/gitlab-org/gitlab/-/issues/344533) by
[`artifacts:reports:coverage_report`](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportscoverage_report).
Cobertura is the only supported report file, but this is the first step towards GitLab supporting other report types.
diff --git a/doc/update/upgrading_from_ce_to_ee.md b/doc/update/upgrading_from_ce_to_ee.md
index d6548620356..b953194b4cf 100644
--- a/doc/update/upgrading_from_ce_to_ee.md
+++ b/doc/update/upgrading_from_ce_to_ee.md
@@ -21,7 +21,7 @@ GitLab edition you are using (Community or Enterprise), see the
This guide assumes you have a correctly configured and tested installation of
GitLab Community Edition. If you run into any trouble or if you have any
-questions please contact us at `support@gitlab.com`.
+questions contact us at `support@gitlab.com`.
In all examples, replace `EE_BRANCH` with the Enterprise Edition branch for the
version you are using, and `CE_BRANCH` with the Community Edition branch.
@@ -41,7 +41,7 @@ cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production
```
-For installations using MySQL, this may require granting "LOCK TABLES"
+For installations using MySQL, this may require granting `LOCK TABLES`
privileges to the GitLab user on the database version.
### 1. Stop server
@@ -88,7 +88,7 @@ sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production
### 4. Install `gitlab-elasticsearch-indexer` **(PREMIUM SELF)**
-Please follow the [install instruction](../integration/advanced_search/elasticsearch.md#install-elasticsearch).
+Follow the [install instruction](../integration/advanced_search/elasticsearch.md#install-elasticsearch).
### 5. Start application
diff --git a/doc/update/upgrading_from_source.md b/doc/update/upgrading_from_source.md
index 29bb956cb54..8b921f6d0ce 100644
--- a/doc/update/upgrading_from_source.md
+++ b/doc/update/upgrading_from_source.md
@@ -8,12 +8,12 @@ comments: false
# Upgrading Community Edition and Enterprise Edition from source **(FREE SELF)**
Make sure you view this update guide from the branch (version) of GitLab you
-would like to install (for example, `11.8`). You can select the required version of documentation in the dropdown at the top right corner of GitLab documentation page.
+would like to install (for example, `11.8`). You can select the required version of documentation in the dropdown list at the top right corner of GitLab documentation page.
In each of the following examples, replace `BRANCH` with the branch of the version you upgrading to (for example, `11-8-stable` for `11.8`). Replace `PREVIOUS_BRANCH` with the
branch for the version you are upgrading from (for example, `11-7-stable` for `11.7`).
-If the highest number stable branch is unclear please check the
+If the highest number stable branch is unclear check the
[GitLab Blog](https://about.gitlab.com/blog/archives.html) for installation
guide links by version.
@@ -24,7 +24,7 @@ the [Upgrading from CE to EE](upgrading_from_ce_to_ee.md) documentation.
Major versions are reserved for backwards incompatible changes. We recommend that
you first upgrade to the latest available minor version of your current major version.
-Please follow the [Upgrade Recommendations](../policy/maintenance.md#upgrade-recommendations)
+Follow the [Upgrade Recommendations](../policy/maintenance.md#upgrade-recommendations)
to identify the ideal upgrade path.
Before upgrading to a new major version, you should ensure that any background
@@ -225,7 +225,7 @@ NGINX configuration to continue using it. This is because the GitLab application
sets it.
If you are using Apache instead of NGINX see the updated [Apache templates](https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache).
-Also note that because Apache does not support upstreams behind Unix sockets you
+Also because Apache does not support upstreams behind Unix sockets you
must let GitLab Workhorse listen on a TCP port. You can do this
via [`/etc/default/gitlab`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/support/init.d/gitlab.default.example#L38).
@@ -406,6 +406,11 @@ sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production
If all items are green, then congratulations, the upgrade is complete!
+### 17. Upgrade the product documentation
+
+This is an optional step. If you [installed the product documentation](../install/installation.md#install-the-product-documentation),
+see how to [upgrade to a later version](../administration/docs_self_host.md#upgrade-the-product-documentation-to-a-later-version).
+
## Version specific upgrading instructions
This section contains upgrading instructions for specific versions. When
@@ -423,7 +428,7 @@ Additional instructions here.
### 15.0.0
Support for more than one database has been added to GitLab. [As part of this](https://gitlab.com/gitlab-org/gitlab/-/issues/338182),
-`config/database.yml` needs to include a database name in the database configuration.
+`config/database.yml` must include a database name in the database configuration.
The `main: database` must be first. If an invalid or deprecated syntax is used, an error is generated
during application start:
@@ -442,7 +447,7 @@ production:
...
```
-Starting with GitLab 15.0, it needs to define a `main` database first:
+Starting with GitLab 15.0, it must define a `main` database first:
```yaml
production:
@@ -487,7 +492,7 @@ for the previous version.
For example, if you have upgraded to GitLab 12.6 and want to revert back to
12.5, follow the guides for upgrading from 12.4 to 12.5. You can
-use the version dropdown at the top of the page to select the right version.
+use the version dropdown list at the top of the page to select the right version.
When reverting, you should **not** follow the database migration guides, as the
backup has already been migrated to the previous version.
diff --git a/doc/update/with_downtime.md b/doc/update/with_downtime.md
index 9357f70e44a..c6ad854fd0f 100644
--- a/doc/update/with_downtime.md
+++ b/doc/update/with_downtime.md
@@ -15,12 +15,12 @@ there are a number of constraints. In particular, you can upgrade to only one mi
at a time, for example, from 14.6 to 14.7, then to 14.8, etc.
If you want to upgrade to more than one minor release at a time (for example, from 14.6 to 14.9),
-you need to take your GitLab instance offline, which implies downtime.
+you must take your GitLab instance offline, which implies downtime.
Before starting this process, verify the
[version specific upgrading instructions](index.md#version-specific-upgrading-instructions)
relevant to your [upgrade path](index.md#upgrade-paths).
-For a single node installation, you only need to [uprgade the GitLab package](package/index.md).
+For a single node installation, you must only [upgrade the GitLab package](package/index.md).
The process for upgrading a number of components of a multi-node GitLab
installation is the same as for zero downtime upgrades.
@@ -86,11 +86,11 @@ for Gitaly cluster.
If you are using Amazon Machine Images (AMIs) on AWS, the Gitaly nodes
**should not be upgraded via the AMI process**. Gitaly nodes should **only**
-be upgraded using the package upgrade. This is because:
+be upgraded using the package upgrade because:
- Praefect tracks replicas of Git repositories by server hostname.
-- Redeployment using AMIs will issue the nodes with new hostnames.
-- Even though the storage will be the same, Gitaly cluster will not work after this.
+- Redeployment using AMIs issues the nodes with new hostnames.
+- Even though the storage is the same, Gitaly cluster does not work after this.
The Praefect nodes, however, can be upgraded via an AMI redeployment process:
@@ -100,7 +100,7 @@ The Praefect nodes, however, can be upgraded via an AMI redeployment process:
1. The first node to be redeployed with the upgraded image should be your
deploy node.
1. After it's deployed, set `praefect['auto_migrate'] = true` in `gitlab.rb`
- and apply with `gitlab-ctl reconfigure`. This will run the database
+ and apply with `gitlab-ctl reconfigure`. This runs the database
migrations.
1. Redeploy your other Praefect nodes.
@@ -142,7 +142,7 @@ For unclustered PostgreSQL servers:
## Upgrade the Patroni node
-Patroni is used to achiece high availabilty with PostgreSQL.
+Patroni is used to achieve high availability with PostgreSQL.
If a PostgreSQL major version upgrade is required,
[follow the major version process](../administration/postgresql/replication_and_failover.md#upgrading-postgresql-major-version-in-a-patroni-cluster).
@@ -150,7 +150,7 @@ If a PostgreSQL major version upgrade is required,
The upgrade process for all other versions is performed on all replicas first.
After they're upgraded, a cluster failover occurs from the leader to one of the upgraded
replicas. This ensures that only one failover is needed, and once complete the new
-leader will be upgraded.
+leader is upgraded.
Follow the following process:
@@ -218,7 +218,7 @@ sudo yum install gitlab-ee
## Upgrade Redis HA (using Sentinel) **(PREMIUM SELF)**
-Follow [the zero downtime instructions](zero_downtime.md#use-redis-ha-using-sentinel)
+Follow [the zero downtime instructions](zero_downtime.md#redis-ha-using-sentinel)
for upgrading your Redis HA cluster.
## Upgrade the Rails nodes (Puma / Sidekiq)
@@ -232,7 +232,7 @@ All the Puma and Sidekiq processes were previously shut down. On each node:
ps -ef | egrep 'puma: | puma | sidekiq '
```
-Select one node that runs Puma. This will be your deploy node, and is responsible for
+Select one node that runs Puma. This is your deploy node, and is responsible for
running all database migrations. On the deploy node:
1. Ensure the server is configured to permit regular migrations. Check that
diff --git a/doc/update/zero_downtime.md b/doc/update/zero_downtime.md
index a3f9886ed0b..3cdc6177a4d 100644
--- a/doc/update/zero_downtime.md
+++ b/doc/update/zero_downtime.md
@@ -27,14 +27,14 @@ If you meet all the requirements above, follow these instructions in order. Ther
| Deployment type | Description |
| --------------------------------------------------------------- | ------------------------------------------------ |
| [Gitaly or Gitaly Cluster](#gitaly-or-gitaly-cluster) | GitLab CE/EE using HA architecture for Gitaly or Gitaly Cluster |
-| [Multi-node / PostgreSQL HA](#use-postgresql-ha) | GitLab CE/EE using HA architecture for PostgreSQL |
-| [Multi-node / Redis HA](#use-redis-ha-using-sentinel) | GitLab CE/EE using HA architecture for Redis |
+| [Multi-node / PostgreSQL HA](#postgresql) | GitLab CE/EE using HA architecture for PostgreSQL |
+| [Multi-node / Redis HA](#redis-ha-using-sentinel) | GitLab CE/EE using HA architecture for Redis |
| [Geo](#geo-deployment) | GitLab EE with Geo enabled |
| [Multi-node / HA with Geo](#multi-node--ha-deployment-with-geo) | GitLab CE/EE on multiple nodes |
Each type of deployment requires that you hot reload the `puma` and `sidekiq` processes on all nodes running these
services after you've upgraded. The reason for this is that those processes each load the GitLab Rails application which reads and loads
-the database schema into memory when starting up. Each of these processes needs to be reloaded (or restarted in the case of `sidekiq`)
+the database schema into memory when starting up. Each of these processes must be reloaded (or restarted in the case of `sidekiq`)
to re-read any database changes that have been made by post-deployment migrations.
Most of the time you can safely upgrade from a patch release to the next minor
@@ -260,7 +260,7 @@ node first and run database migrations.
sudo gitlab-ctl reconfigure
```
-### Use PostgreSQL HA
+### PostgreSQL
Pick a node to be the `Deploy Node`. It can be any application node, but it must be the same
node throughout the process.
@@ -277,7 +277,7 @@ node throughout the process.
- To prevent `reconfigure` from automatically running database migrations, ensure that `gitlab_rails['auto_migrate'] = false` is set in `/etc/gitlab/gitlab.rb`.
-**Gitaly only nodes**
+**PostgreSQL only nodes**
- Update the GitLab package
@@ -313,7 +313,7 @@ node throughout the process.
- If you're using PgBouncer:
- You need to bypass PgBouncer and connect directly to the database leader
+ You must bypass PgBouncer and connect directly to the database leader
before running migrations.
Rails uses an advisory lock when attempting to run a migration to prevent
@@ -385,7 +385,7 @@ sure you remove `/etc/gitlab/skip-auto-reconfigure` and revert
setting `gitlab_rails['auto_migrate'] = false` in
`/etc/gitlab/gitlab.rb` after you've completed these steps.
-### Use Redis HA (using Sentinel) **(PREMIUM SELF)**
+### Redis HA (using Sentinel) **(PREMIUM SELF)**
Package upgrades may involve version updates to the bundled Redis service. On
instances using [Redis for scaling](../administration/redis/index.md),
@@ -395,11 +395,11 @@ HA.
#### In the application node
-According to [official Redis docs](https://redis.io/topics/admin#upgrading-or-restarting-a-redis-instance-without-downtime),
+According to [official Redis documentation](https://redis.io/topics/admin#upgrading-or-restarting-a-redis-instance-without-downtime),
the easiest way to update an HA instance using Sentinel is to upgrade the
secondaries one after the other, perform a manual failover from current
primary (running old version) to a recently upgraded secondary (running a new
-version), and then upgrade the original primary. For this, we need to know
+version), and then upgrade the original primary. For this, we must know
the address of the current Redis primary.
- If your application node is running GitLab 12.7.0 or later, you can use the
@@ -416,7 +416,7 @@ following command to get address of current Redis primary
1. Get the address of one of the sentinel nodes specified as
`gitlab_rails['redis_sentinels']` in `/etc/gitlab/gitlab.rb`
- 1. Get the Redis master name specified as `redis['master_name']` in
+ 1. Get the Redis main name specified as `redis['master_name']` in
`/etc/gitlab/gitlab.rb`
1. Run the following command
@@ -427,6 +427,8 @@ following command to get address of current Redis primary
#### In the Redis secondary nodes
+1. Set `gitlab_rails['rake_cache_clear'] = false` in `gitlab.rb` if you haven't already. If not, you might receive the error `Redis::CommandError: READONLY You can't write against a read only replica.` during the reconfigure post installation of new package.
+
1. Install package for new version.
1. Run `sudo gitlab-ctl reconfigure`, if a reconfigure is not run as part of
@@ -442,8 +444,8 @@ following command to get address of current Redis primary
#### In the Redis primary node
-Before upgrading the Redis primary node, we need to perform a failover so that
-one of the recently upgraded secondary nodes becomes the new primary. Once the
+Before upgrading the Redis primary node, we must perform a failover so that
+one of the recently upgraded secondary nodes becomes the new primary. After the
failover is complete, we can go ahead and upgrade the original primary node.
1. Stop Redis service in Redis primary node so that it fails over to a secondary
@@ -623,7 +625,7 @@ Updates must be performed in the following order:
### Step 1: Choose a "deploy node" for each deployment
-You now need to choose:
+You now must choose:
- One instance for use as the **primary** "deploy node" on the Geo **primary** multi-node deployment.
- One instance for use as the **secondary** "deploy node" on each Geo **secondary** multi-node deployment.
@@ -696,7 +698,7 @@ sudo touch /etc/gitlab/skip-auto-reconfigure
1. If you're using PgBouncer:
- You need to bypass PgBouncer and connect directly to the database leader
+ You must bypass PgBouncer and connect directly to the database leader
before running migrations.
Rails uses an advisory lock when attempting to run a migration to prevent
View Lorry Controller Status