Merge branch 'docs-axil-omnibus-update' into 'master'

Update Omnibus links to new doc/update/ location

See merge request gitlab-org/gitlab!70392

doc/administration/geo/replication/updating_the_geo_sites.md

@@ -21,16 +21,18 @@ Updating Geo sites involves performing:
 ## General update steps
 
 NOTE:
-These general update steps are not intended for [high-availability deployments](https://docs.gitlab.com/omnibus/update/README.html#multi-node--ha-deployment), and will cause downtime. If you want to avoid downtime, consider using [zero downtime updates](https://docs.gitlab.com/omnibus/update/README.html#zero-downtime-updates).
+These general update steps are not intended for multi-site deployments,
+and will cause downtime. If you want to avoid downtime, consider using
+[zero downtime upgrades](../../../update/zero_downtime.md#multi-node--ha-deployment-with-geo).
 
 To update the Geo sites when a new GitLab version is released, update **primary**
 and all **secondary** sites:
 
 1. **Optional:** [Pause replication on each **secondary** sites.](../index.md#pausing-and-resuming-replication)
 1. SSH into each node of the **primary** site.
-1. [Update GitLab on the **primary** site using Omnibus](https://docs.gitlab.com/omnibus/update/#update-using-the-official-repositories).
+1. [Upgrade GitLab on the **primary** site](../../../update/package/index.md#upgrade-using-the-official-repositories).
 1. SSH into each node of **secondary** sites.
-1. [Update GitLab on each **secondary** site using Omnibus](https://docs.gitlab.com/omnibus/update/#update-using-the-official-repositories).
+1. [Upgrade GitLab on each **secondary** site](../../../update/package/index.md#upgrade-using-the-official-repositories).
 1. If you paused replication in step 1, [resume replication on each **secondary**](../index.md#pausing-and-resuming-replication)
 1. [Test](#check-status-after-updating) **primary** and **secondary** sites, and check version in each.
 

doc/administration/geo/replication/version_specific_updates.md

@@ -312,7 +312,7 @@ GitLab 12.2 includes the following minor PostgreSQL updates:
 
 This update occurs even if major PostgreSQL updates are disabled.
 
-Before [refreshing Foreign Data Wrapper during a Geo upgrade](https://docs.gitlab.com/omnibus/update/README.html#run-post-deployment-migrations-and-checks),
+Before [refreshing Foreign Data Wrapper during a Geo upgrade](../../../update/zero_downtime.md#step-4-run-post-deployment-migrations-and-checks),
 restart the Geo tracking database:
 
 ```shell

doc/administration/gitaly/configure_gitaly.md

@@ -41,9 +41,8 @@ However, Gitaly can be deployed to its own server, which can benefit GitLab inst
 multiple machines.
 
 NOTE:
-When configured to run on their own servers, Gitaly servers
-[must be upgraded](https://docs.gitlab.com/omnibus/update/#upgrading-gitaly-servers) before Gitaly
-clients in your cluster.
+When configured to run on their own servers, Gitaly servers must be
+[upgraded](../../update/package/index.md) before Gitaly clients in your cluster.
 
 The process for setting up Gitaly on its own server is:
 

doc/administration/gitaly/praefect.md

@@ -20,10 +20,6 @@ Configure Gitaly Cluster using either:
 
 Smaller GitLab installations may need only [Gitaly itself](index.md).
 
-NOTE:
-Upgrade instructions for Omnibus GitLab installations
-[are available](https://docs.gitlab.com/omnibus/update/#gitaly-cluster).
-
 ## Requirements
 
 The minimum recommended configuration for a Gitaly Cluster requires:

doc/administration/postgresql/pgbouncer.md

@@ -173,7 +173,7 @@ ote_pid | tls
 Some database changes have to be done directly, and not through PgBouncer.
 
 Read more about the affected tasks: [database restores](../../raketasks/backup_restore.md#backup-and-restore-for-installations-using-pgbouncer)
-and [GitLab upgrades](https://docs.gitlab.com/omnibus/update/README.html#use-postgresql-ha).
+and [GitLab upgrades](../../update/zero_downtime.md#use-postgresql-ha).
 
 1. To find the primary node, run the following on a database node:
 

doc/administration/reference_architectures/index.md

@@ -139,8 +139,8 @@ to any of the [available reference architectures](#available-reference-architect
 > - Level of complexity: **Medium**
 > - Required domain knowledge: PostgreSQL, HAProxy, shared storage, distributed systems
 
-GitLab supports [zero-downtime updates](https://docs.gitlab.com/omnibus/update/#zero-downtime-updates).
-Single GitLab nodes can be updated with only a [few minutes of downtime](https://docs.gitlab.com/omnibus/update/README.html#single-node-deployment).
+GitLab supports [zero-downtime upgrades](../../update/zero_downtime.md).
+Single GitLab nodes can be updated with only a [few minutes of downtime](../../update/zero_downtime.md#single-node-deployment).
 To avoid this, we recommend to separate GitLab into several application nodes.
 As long as at least one of each component is online and capable of handling the instance's usage load, your team's productivity will not be interrupted during the update.
 

doc/development/multi_version_compatibility.md

@@ -124,7 +124,7 @@ GitLab.com, the feature can be enabled in ChatOps and validated on GitLab.com.
 
 **However, it is not necessarily safe to enable the feature by default.** If the
 feature flag is removed, or the default is flipped to enabled, in the same release
-where the code was merged, then customers performing [zero-downtime updates](https://docs.gitlab.com/omnibus/update/#zero-downtime-updates)
+where the code was merged, then customers performing [zero-downtime updates](../update/zero_downtime.md)
 will end up running the new frontend code against the previous release's API.
 
 If you're not sure whether it's safe to enable all the changes at once, then one

doc/policy/maintenance.md

@@ -64,10 +64,10 @@ one major version. For example, it is safe to:
   - `12.10.1` -> `12.10.8`
 
 NOTE:
-Version specific changes in Omnibus GitLab Linux packages can be found in [the Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/update/README.html#version-specific-changes).
+Version specific changes in Omnibus GitLab Linux packages can be found in [the Omnibus GitLab documentation](../update/package/index.md#version-specific-changes).
 
 NOTE:
-Instructions are available for downloading an Omnibus GitLab Linux package locally and [manually installing](https://docs.gitlab.com/omnibus/manual_install.html) it.
+Instructions are available for downloading an Omnibus GitLab Linux package locally and [manually installing](../update/package/index.md#upgrade-using-a-manually-downloaded-package) it.
 
 NOTE:
 A step-by-step guide to [upgrading the Omnibus-bundled PostgreSQL is documented separately](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server).

doc/raketasks/backup_restore.md

@@ -810,7 +810,7 @@ You can restore a backup only to _the exact same version and type (CE/EE)_ of
 GitLab that you created it on (for example CE 9.1.0).
 
 If your backup is a different version than the current installation, you must
-[downgrade your GitLab installation](https://docs.gitlab.com/omnibus/update/README.html#downgrade)
+[downgrade your GitLab installation](../update/package/downgrade.md)
 before restoring the backup.
 
 ### Restore prerequisites

doc/update/index.md

@@ -32,12 +32,12 @@ official ways to update GitLab:
 
 ### Linux packages (Omnibus GitLab)
 
-The [Omnibus update guide](https://docs.gitlab.com/omnibus/update/)
+The [package upgrade guide](package/index.md)
 contains the steps needed to update a package installed by official GitLab
 repositories.
 
 There are also instructions when you want to
-[update to a specific version](https://docs.gitlab.com/omnibus/update/#multi-step-upgrade-using-the-official-repositories).
+[update to a specific version](package/index.md#upgrade-to-a-specific-version-using-the-official-repositories).
 
 ### Installation from source
 
@@ -186,7 +186,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`](#upgrades-from-versions-earlier-than-812) -> `8.17.7` -> `9.5.10` -> `10.8.7` -> [`11.11.8`](#1200) -> `12.0.12` -> [`12.1.17`](#1210) -> `12.10.14` -> `13.0.14` -> [`13.1.11`](#1310) -> [`13.8.8`](#1388) -> [latest `13.12.Z`](https://about.gitlab.com/releases/categories/releases/) -> [latest `14.0.Z`](#1400) -> [latest `14.Y.Z`](https://about.gitlab.com/releases/categories/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` -> `13.0.14` -> [`13.1.11`](#1310) -> [`13.8.8`](#1388) -> [latest `13.12.Z`](https://about.gitlab.com/releases/categories/releases/) -> [latest `14.0.Z`](#1400) -> [latest `14.Y.Z`](https://about.gitlab.com/releases/categories/releases/)
 
 The following table, while not exhaustive, shows some examples of the supported
 upgrade paths.
@@ -255,7 +255,7 @@ Edition, follow the guides below based on the installation method:
   to a version upgrade: stop the server, get the code, update configuration files for
   the new functionality, install libraries and do migrations, update the init
   script, start the application and check its status.
-- [Omnibus CE to EE](https://docs.gitlab.com/omnibus/update/README.html#update-community-edition-to-enterprise-edition) - Follow this guide to update your Omnibus
+- [Omnibus CE to EE](package/convert_to_ee.md) - Follow this guide to update your Omnibus
   GitLab Community Edition to the Enterprise Edition.
 
 ### Enterprise to Community Edition
@@ -286,7 +286,7 @@ These include:
 Apart from the instructions in this section, you should also check the
 installation-specific upgrade instructions, based on how you installed GitLab:
 
-- [Linux packages (Omnibus GitLab)](https://docs.gitlab.com/omnibus/update/README.html#version-specific-changes)
+- [Linux packages (Omnibus GitLab)](../update/package/index.md#version-specific-changes)
 - [Helm charts](https://docs.gitlab.com/charts/installation/upgrade.html)
 
 NOTE:
@@ -496,7 +496,7 @@ The Rails upgrade included a change to CSRF token generation which is
 not backwards-compatible - GitLab servers with the new Rails version
 generate CSRF tokens that are not recognizable by GitLab servers
 with the older Rails version - which could cause non-GET requests to
-fail for [multi-node GitLab installations](https://docs.gitlab.com/omnibus/update/#multi-node--ha-deployment).
+fail for [multi-node GitLab installations](zero_downtime.md#multi-node--ha-deployment).
 
 So, if you are using multiple Rails servers and specifically upgrading from 13.0,
 all servers must first be upgraded to 13.1.Z before upgrading to 13.2.0 or later:
@@ -545,12 +545,6 @@ After upgraded to 11.11.8 you can safely upgrade to 12.0.Z.
 See our [documentation on upgrade paths](../policy/maintenance.md#upgrade-recommendations)
 for more information.
 
-### Upgrades from versions earlier than 8.12
-
-- `8.11.Z` and earlier: you might have to upgrade to `8.12.0` specifically before you can upgrade to `8.17.7`. This was [reported in an issue](https://gitlab.com/gitlab-org/gitlab/-/issues/207259).
-- [CI changes prior to version 8.0](https://docs.gitlab.com/omnibus/update/README.html#updating-gitlab-ci-from-prior-540-to-version-714-via-omnibus-gitlab)
-  when it was merged into GitLab.
-
 ## Miscellaneous
 
 - [MySQL to PostgreSQL](mysql_to_postgresql.md) guides you through migrating

doc/update/plan_your_upgrade.md

@@ -106,15 +106,15 @@ to your instance and then upgrade it for any relevant features you're using.
     - [Compiled from source](index.md#installation-from-source)
     - [Docker](index.md#installation-using-docker)
     - [Helm Charts](index.md#installation-using-helm)
-  - [Zero-downtime updates](https://docs.gitlab.com/omnibus/update/#zero-downtime-updates) ([if possible](index.md#upgrading-without-downtime) and desired)
-  - [Upgrade from GitLab Community Edition to Enterprise Edition, or vice-versa](https://docs.gitlab.com/omnibus/update/#upgrade-community-edition-to-enterprise-edition)
+  - [Zero-downtime upgrades](zero_downtime.md) (if possible and desired)
+  - [Convert from GitLab Community Edition to Enterprise Edition](package/convert_to_ee.md)
 - What version should you upgrade to:
   - [Determine what upgrade path](index.md#upgrade-paths) to follow.
   - Account for any [version-specific update instructions](index.md#version-specific-upgrading-instructions).
-  - Account for any [version-specific changes](https://docs.gitlab.com/omnibus/update/#version-specific-changes).
+  - Account for any [version-specific changes](package/index.md#version-specific-changes).
   - Check the [OS compatibility with the target GitLab version](https://docs.gitlab.com/omnibus/package-information/deprecated_os.html).
-- Due to [background migrations](https://docs.gitlab.com/omnibus/update/#background-migrations),
-  plan to pause any further upgrades after updating to a new major version.
+- Due to background migrations, plan to pause any further upgrades after upgrading
+  to a new major version.
   [All migrations must finish running](index.md#checking-for-background-migrations-before-upgrading)
   before the next upgrade.
 - If available in your starting version, consider
@@ -138,9 +138,8 @@ such as Geo, external Gitaly, or Elasticsearch.
 
 #### External Gitaly
 
-If you're using an external Gitaly server, read the
-[upgrade Gitaly](https://docs.gitlab.com/omnibus/update/#upgrade-gitaly-servers)
-documentation.
+If you're using an external Gitaly server, it must be upgraded to the newer
+version prior to upgrading the application server.
 
 #### Geo