From 4589a594feedbac2990d85e5be9ed2e90c034f51 Mon Sep 17 00:00:00 2001
From: Craig Norris <cnorris@gitlab.com>
Date: Thu, 14 Oct 2021 12:51:41 +0000
Subject: [PATCH] Remove references to outdated GitLab versions
Remove references to outdated GitLab versions
---
doc/administration/object_storage.md | 5 +-
doc/administration/raketasks/github_import.md | 2 -
.../raketasks/project_import_export.md | 3 --
doc/api/sidekiq_metrics.md | 2 -
doc/install/requirements.md | 8 ++--
doc/update/zero_downtime.md | 46 +++++++++----------
6 files changed, 28 insertions(+), 38 deletions(-)
diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md
index 6c77576cb27e..83f3118556df 100644
--- a/doc/administration/object_storage.md
+++ b/doc/administration/object_storage.md
@@ -2,7 +2,6 @@
stage: Enablement
group: Distribution
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-type: reference
---
# Object storage **(FREE SELF)**
@@ -123,8 +122,8 @@ See the section on [ETag mismatch errors](#etag-mismatch) for more details.
gitlab_rails['object_store']['objects']['pages']['bucket'] = '<pages>'
```
- For GitLab 9.4 or later, if you're using AWS IAM profiles, be sure to omit the
- AWS access key and secret access key/value pairs. For example:
+ If you're using AWS IAM profiles, omit the AWS access key and secret access
+ key/value pairs. For example:
```ruby
gitlab_rails['object_store']['connection'] = {
diff --git a/doc/administration/raketasks/github_import.md b/doc/administration/raketasks/github_import.md
index f29e2a6c7f66..0cdfd1c28ff1 100644
--- a/doc/administration/raketasks/github_import.md
+++ b/doc/administration/raketasks/github_import.md
@@ -6,8 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# GitHub import **(FREE SELF)**
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/10308) in GitLab 9.1.
-
To retrieve and import GitHub repositories, you need a [GitHub personal access token](https://github.com/settings/tokens).
A username should be passed as the second argument to the Rake task,
which becomes the owner of the project. You can resume an import
diff --git a/doc/administration/raketasks/project_import_export.md b/doc/administration/raketasks/project_import_export.md
index e0ca7bfdeaf4..13f8dfdccc22 100644
--- a/doc/administration/raketasks/project_import_export.md
+++ b/doc/administration/raketasks/project_import_export.md
@@ -6,9 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Project import/export administration **(FREE SELF)**
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/3050) in GitLab 8.9.
-> - From GitLab 11.3, import/export can use object storage automatically.
-
GitLab provides Rake tasks relating to project import and export. For more information, see:
- [Project import/export documentation](../../user/project/settings/import_export.md).
diff --git a/doc/api/sidekiq_metrics.md b/doc/api/sidekiq_metrics.md
index bcb59a6dad39..2be2e71e551f 100644
--- a/doc/api/sidekiq_metrics.md
+++ b/doc/api/sidekiq_metrics.md
@@ -6,8 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Sidekiq Metrics API **(FREE SELF)**
-> Introduced in GitLab 8.9.
-
This API endpoint allows you to retrieve some information about the current state
of Sidekiq, its jobs, queues, and processes.
diff --git a/doc/install/requirements.md b/doc/install/requirements.md
index c136fb21a90b..70b6de9b4277 100644
--- a/doc/install/requirements.md
+++ b/doc/install/requirements.md
@@ -2,7 +2,6 @@
stage: Enablement
group: Distribution
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-type: reference
---
# Installation requirements **(FREE SELF)**
@@ -119,7 +118,6 @@ the following table) as these were used for development and testing:
| GitLab version | Minimum PostgreSQL version |
|----------------|----------------------------|
-| 10.0 | 9.6 |
| 13.0 | 11 |
| 14.0 | 12 |
@@ -272,9 +270,9 @@ On a very active server (10,000 billable users) the Sidekiq process can use 1GB+
## Prometheus and its exporters
-As of Omnibus GitLab 9.0, [Prometheus](https://prometheus.io) and its related
-exporters are enabled by default, to enable easy and in depth monitoring of
-GitLab. With default settings, these processes consume approximately 200MB of memory.
+[Prometheus](https://prometheus.io) and its related exporters are enabled by
+default to enable in depth monitoring of GitLab. With default settings, these
+processes consume approximately 200 MB of memory.
If you would like to disable Prometheus and it's exporters or read more information
about it, check the [Prometheus documentation](../administration/monitoring/prometheus/index.md).
diff --git a/doc/update/zero_downtime.md b/doc/update/zero_downtime.md
index 7a74435267f1..6f00aa3b72bc 100644
--- a/doc/update/zero_downtime.md
+++ b/doc/update/zero_downtime.md
@@ -1,17 +1,17 @@
---
stage: Enablement
group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Zero downtime upgrades **(FREE SELF)**
-Starting with GitLab 9.1.0 it's possible to upgrade to a newer major, minor, or
-patch version of GitLab without having to take your GitLab instance offline.
-However, for this to work there are the following requirements:
+It's possible to upgrade to a newer major, minor, or patch version of GitLab
+without having to take your GitLab instance offline. However, for this to work
+there are the following requirements:
-- You can only upgrade 1 minor release at a time. So from 9.1 to 9.2, not to
- 9.3. If you skip releases, database modifications may be run in the wrong
+- You can only upgrade one minor release at a time. So from 13.1 to 13.2, not to
+ 13.3. If you skip releases, database modifications may be run in the wrong
sequence [and leave the database schema in a broken state](https://gitlab.com/gitlab-org/gitlab/-/issues/321542).
- You have to use [post-deployment migrations](../development/post_deployment_migrations.md).
- You are using PostgreSQL. Starting from GitLab 12.1, MySQL is not supported.
@@ -36,10 +36,10 @@ to re-read any database changes that have been made by post-deployment migration
Most of the time you can safely upgrade from a patch release to the next minor
release if the patch release is not the latest. For example, upgrading from
-9.1.1 to 9.2.0 should be safe even if 9.1.2 has been released. We do recommend
+14.1.1 to 14.2.0 should be safe even if 14.1.2 has been released. We do recommend
you check the release posts of any releases between your current and target
version just in case they include any migrations that may require you to upgrade
-1 release at a time.
+one release at a time.
Some releases may also include so called "background migrations". These
migrations are performed in the background by Sidekiq and are often used for
@@ -63,21 +63,21 @@ the migrations that are being performed.
To help explain this, let's look at some examples:
-**Example 1:** You are running a large GitLab installation using version 9.4.2,
-which is the latest patch release of 9.4. When GitLab 9.5.0 is released this
-installation can be safely upgraded to 9.5.0 without requiring downtime if the
-requirements mentioned above are met. You can also skip 9.5.0 and upgrade to
-9.5.1 after it's released, but you **can not** upgrade straight to 9.6.0; you
-_have_ to first upgrade to a 9.5.Z release.
-
-**Example 2:** You are running a large GitLab installation using version 9.4.2,
-which is the latest patch release of 9.4. GitLab 9.5 includes some background
-migrations, and 10.0 requires these to be completed (processing any
-remaining jobs for you). Skipping 9.5 is not possible without downtime, and due
+**Example 1:** You are running a large GitLab installation using version 13.4.2,
+which is the latest patch release of 13.4. When GitLab 13.5.0 is released this
+installation can be safely upgraded to 13.5.0 without requiring downtime if the
+requirements mentioned above are met. You can also skip 13.5.0 and upgrade to
+13.5.1 after it's released, but you **can not** upgrade straight to 13.6.0; you
+_have_ to first upgrade to a 13.5.Z release.
+
+**Example 2:** You are running a large GitLab installation using version 13.4.2,
+which is the latest patch release of 13.4. GitLab 13.5 includes some background
+migrations, and 14.0 requires these to be completed (processing any
+remaining jobs for you). Skipping 13.5 is not possible without downtime, and due
to the background migrations would require potentially hours of downtime
depending on how long it takes for the background migrations to complete. To
-work around this you have to upgrade to 9.5.Z first, then wait at least a
-week before upgrading to 10.0.
+work around this you have to upgrade to 13.5.Z first, then wait at least a
+week before upgrading to 14.0.
**Example 3:** You use MySQL as the database for GitLab. Any upgrade to a new
major/minor release requires downtime. If a release includes any background
@@ -89,7 +89,7 @@ meet the other online upgrade requirements mentioned above.
Before following these instructions, note the following **important** information:
-- You can only upgrade 1 minor release at a time. So from 13.6 to 13.7, not to 13.8.
+- You can only upgrade one minor release at a time. So from 13.6 to 13.7, not to 13.8.
If you attempt more than one minor release, the upgrade may fail.
- On single-node Omnibus deployments, updates with no downtime are not possible when
using Puma because Puma always requires a complete restart. This is because the
@@ -156,7 +156,7 @@ you've completed these steps.
## Multi-node / HA deployment
-You can only upgrade 1 minor release at a time. So from 13.6 to 13.7, not to 13.8.
+You can only upgrade one minor release at a time. So from 13.6 to 13.7, not to 13.8.
If you attempt more than one minor release, the upgrade may fail.
### Use a load balancer in front of web (Puma) nodes
--
GitLab