Remove superfluous blank lines

More cleanup

doc/administration/geo/disaster_recovery/planned_failover.md

@@ -45,7 +45,7 @@ be adapted for use with any other file-based data, such as [GitLab Pages](../../
 ### Container registry
 
 By default, the container registry is not automatically replicated to secondary
-sites and this needs to be manually configured, see [Docker Registry for a secondary site](../replication/docker_registry.md).
+sites and this needs to be manually configured, see [Container Registry for a secondary site](../replication/container_registry.md).
 
 If you are using local storage on your current primary site for the container
 registry, you can `rsync` the container registry objects to the secondary

doc/administration/geo/index.md

@@ -283,7 +283,7 @@ For information on using Geo in disaster recovery situations to mitigate data-lo
 
 ### Replicating the Container Registry
 
-For more information on how to replicate the Container Registry, see [Docker Registry for a **secondary** site](replication/docker_registry.md).
+For more information on how to replicate the Container Registry, see [Container Registry for a **secondary** site](replication/container_registry.md).
 
 ### Geo secondary proxy
 

doc/administration/geo/replication/container_registry.md

+---
+stage: Systems
+group: Geo
+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: howto
+---
+
+# Container Registry for a secondary site **(PREMIUM SELF)**
+
+You can set up a Container Registry on your **secondary** Geo site that mirrors the one on the **primary** Geo site.
+
+## Supported container registries
+
+Geo supports the following types of container registries:
+ 
+- [Docker](https://docs.docker.com/registry/)
+- [OCI](https://github.com/opencontainers/distribution-spec/blob/main/spec.md)
+
+## Supported image formats
+
+The following container image formats are support by Geo:
+
+- [Docker V2, schema 1](https://docs.docker.com/registry/spec/manifest-v2-1/)
+- [Docker V2, schema 2](https://docs.docker.com/registry/spec/manifest-v2-2/)
+- [OCI (Open Container Initiative)](https://github.com/opencontainers/image-spec)
+
+In addition, Geo also supports [BuildKit cache images](https://github.com/moby/buildkit).
+
+## Supported storage 
+
+### Docker
+
+For more information on supported registry storage drivers see
+[Docker registry storage drivers](https://docs.docker.com/registry/storage-drivers/)
+
+Read the [Load balancing considerations](https://docs.docker.com/registry/deploying/#load-balancing-considerations)
+when deploying the Registry, and how to set up the storage driver for the GitLab integrated 
+[Container Registry](../../packages/container_registry.md#use-object-storage).
+
+### Registries that support OCI artifacts
+
+The following registries support OCI artifacts:
+
+- CNCF Distribution - local/offline verification
+- Azure Container Registry (ACR)
+- Amazon Elastic Container Registry (ECR)
+- Google Artifact Registry (GAR)
+- GitHub Packages container registry (GHCR)
+- Bundle Bar
+
+For more information, see the [OCI Distribution Specification](https://github.com/opencontainers/distribution-spec).
+
+## Configure Container Registry replication
+
+You can enable a storage-agnostic replication so it
+can be used for cloud or local storage. Whenever a new image is pushed to the
+**primary** site, each **secondary** site pulls it to its own container
+repository.
+
+To configure Container Registry replication:
+
+1. Configure the [**primary** site](#configure-primary-site).
+1. Configure the [**secondary** site](#configure-secondary-site).
+1. Verify Container Registry [replication](#verify-replication).
+
+### Configure **primary** site
+
+Make sure that you have Container Registry set up and working on
+the **primary** site before following the next steps.
+
+We need to make Container Registry send notification events to the
+**primary** site.
+
+1. SSH into your GitLab **primary** server and login as root:
+
+   ```shell
+   sudo -i
+   ```
+
+1. Edit `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+   registry['notifications'] = [
+     {
+       'name' => 'geo_event',
+       'url' => 'https://<example.com>/api/v4/container_registry_event/events',
+       'timeout' => '500ms',
+       'threshold' => 5,
+       'backoff' => '1s',
+       'headers' => {
+         'Authorization' => ['<replace_with_a_secret_token>']
+       }
+     }
+   ]
+   ```
+
+   NOTE:
+   Replace `<example.com>` with the `external_url` defined in your primary site's `/etc/gitlab/gitlab.rb` file, and
+   replace `<replace_with_a_secret_token>` with a case sensitive alphanumeric string
+   that starts with a letter. You can generate one with `< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32 | sed "s/^[0-9]*//"; echo`
+
+   NOTE:
+   If you use an external Registry (not the one integrated with GitLab), you must add
+   these settings to its configuration yourself. In this case, you also have to specify
+   notification secret in `registry.notification_secret` section of
+   `/etc/gitlab/gitlab.rb` file.
+
+   NOTE:
+   If you use GitLab HA, you also have to specify
+   the notification secret in `registry.notification_secret` section of
+   `/etc/gitlab/gitlab.rb` file for every web node.
+
+1. Reconfigure the **primary** node for the change to take effect:
+
+   ```shell
+   gitlab-ctl reconfigure
+   ```
+
+### Configure **secondary** site
+
+Make sure you have Container Registry set up and working on
+the **secondary** site before following the next steps.
+
+The following steps should be done on each **secondary** site you're
+expecting to see the container images replicated.
+
+Because we need to allow the **secondary** site to communicate securely with
+the **primary** site Container Registry, we need to have a single key
+pair for all the sites. The **secondary** site uses this key to
+generate a short-lived JWT that is pull-only-capable to access the
+**primary** site Container Registry.
+
+For each application and Sidekiq node on the **secondary** site:
+
+1. SSH into the node and login as the `root` user:
+
+   ```shell
+   sudo -i
+   ```
+
+1. Copy `/var/opt/gitlab/gitlab-rails/etc/gitlab-registry.key` from the **primary** to the node.
+
+1. Edit `/etc/gitlab/gitlab.rb` and add:
+
+   ```ruby
+   gitlab_rails['geo_registry_replication_enabled'] = true
+
+   # Primary registry's hostname and port, it will be used by
+   # the secondary node to directly communicate to primary registry
+   gitlab_rails['geo_registry_replication_primary_api_url'] = 'https://primary.example.com:5050/'
+   ```
+
+1. Reconfigure the node for the change to take effect:
+
+   ```shell
+   gitlab-ctl reconfigure
+   ```
+
+### Verify replication
+
+To verify Container Registry replication is working, on the **secondary** site:
+
+1. On the top bar, select **Menu > Admin**.
+1. On the left sidebar, select **Geo > Nodes**.
+   The initial replication, or "backfill", is probably still in progress.
+
+You can monitor the synchronization process on each Geo site from the **primary** site's **Geo Nodes** dashboard in your browser.

doc/administration/geo/replication/datatypes.md

@@ -194,7 +194,7 @@ successfully, you must replicate their data using some other means.
 |[Project snippets](../../../user/snippets.md)                                                                  | **Yes** (10.2)                                                          | **Yes** (10.2)                                                             | N/A                                                                 | N/A                                                             |       |
 |[CI job artifacts](../../../ci/pipelines/job_artifacts.md)                                                     | **Yes** (10.4)                                                          | **Yes** (14.10)                                                            | [**Yes** (15.1)](https://gitlab.com/groups/gitlab-org/-/epics/5551) | [No](object_storage.md#verification-of-files-in-object-storage) | Verification is behind the feature flag `geo_job_artifact_replication`, enabled by default in 14.10. |
 |[CI Pipeline Artifacts](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/ci/pipeline_artifact.rb) | [**Yes** (13.11)](https://gitlab.com/gitlab-org/gitlab/-/issues/238464) | [**Yes** (13.11)](https://gitlab.com/gitlab-org/gitlab/-/issues/238464)    | [**Yes** (15.1)](https://gitlab.com/groups/gitlab-org/-/epics/5551) | [No](object_storage.md#verification-of-files-in-object-storage) | Persists additional artifacts after a pipeline completes. |
-|[Container Registry](../../packages/container_registry.md)                                                     | **Yes** (12.3)                                                          | No                                                                         | No                                                                  | No                                                              | Disabled by default. See [instructions](docker_registry.md) to enable. |
+|[Container Registry](../../packages/container_registry.md)                                                     | **Yes** (12.3)                                                          | No                                                                         | No                                                                  | No                                                              | Disabled by default. See [instructions](container_registry.md) to enable. |
 |[Infrastructure Registry](../../../user/packages/infrastructure_registry/index.md)                             | **Yes** (14.0)                                                          | **Yes** (14.0)                                                             | [**Yes** (15.1)](https://gitlab.com/groups/gitlab-org/-/epics/5551) | [No](object_storage.md#verification-of-files-in-object-storage) | Behind feature flag `geo_package_file_replication`, enabled by default. |
 |[Project designs repository](../../../user/project/issues/design_management.md)                                | **Yes** (12.7)                                                          | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/32467)                  | N/A                                                                 | N/A                                                             | Designs also require replication of LFS objects and Uploads. |
 |[Package Registry](../../../user/packages/package_registry/index.md)                                           | **Yes** (13.2)                                                          | **Yes** (13.10)                                                            | [**Yes** (15.1)](https://gitlab.com/groups/gitlab-org/-/epics/5551) | [No](object_storage.md#verification-of-files-in-object-storage) | Behind feature flag `geo_package_file_replication`, enabled by default. |

doc/administration/geo/replication/docker_registry.md

 ---
-stage: Systems
-group: Geo
-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: howto
+redirect_to: 'container_registry.md'
+remove_date: '2022-10-29'
 ---
 
-# Container Registry for a secondary site **(PREMIUM SELF)**
+This document was moved to [another location](container_registry.md).
 
-You can set up a Container Registry on your
-**secondary** Geo site that mirrors the one on the **primary** Geo site.
-
-## Registry support
-
-Geo supports the following type of container registries: 
-
-- [Docker](https://docs.docker.com/registry/)
-- [OCI](https://github.com/opencontainers/distribution-spec/blob/main/spec.md)
-
-## Storage support
-
-### Docker
-
-[Docker Registry](https://docs.docker.com/registry/) currently supports a few types of storage. If you choose a
-distributed storage (`azure`, `gcs`, `s3`, `swift`, or `oss`) for your Container
-Registry on the **primary** site, you can use the same storage for a **secondary**
-Container Registry as well. For more information, read the
-[Load balancing considerations](https://docs.docker.com/registry/deploying/#load-balancing-considerations)
-when deploying the Registry, and how to set up the storage driver for the GitLab
-integrated [Container Registry](../../packages/container_registry.md#use-object-storage).
-
-### Registries that support OCI artifacts
-
-The following registries support OCI artifacts:
-
-- CNCF Distribution - local/offline verification
-- Azure Container Registry (ACR)
-- Amazon Elastic Container Registry (ECR)
-- Google Artifact Registry (GAR)
-- GitHub Packages container registry (GHCR)
-- Bundle Bar
-
-For more information, see the [OCI Distribution Specification](https://github.com/opencontainers/distribution-spec).
-
-## Configure Container Registry replication
-
-You can enable a storage-agnostic replication so it
-can be used for cloud or local storage. Whenever a new image is pushed to the
-**primary** site, each **secondary** site pulls it to its own container
-repository.
-
-To configure Container Registry replication:
-
-1. Configure the [**primary** site](#configure-primary-site).
-1. Configure the [**secondary** site](#configure-secondary-site).
-1. Verify Container Registry [replication](#verify-replication).
-
-### Configure **primary** site
-
-Make sure that you have Container Registry set up and working on
-the **primary** site before following the next steps.
-
-We need to make Container Registry send notification events to the
-**primary** site.
-
-1. SSH into your GitLab **primary** server and login as root:
-
-   ```shell
-   sudo -i
-   ```
-
-1. Edit `/etc/gitlab/gitlab.rb`:
-
-   ```ruby
-   registry['notifications'] = [
-     {
-       'name' => 'geo_event',
-       'url' => 'https://<example.com>/api/v4/container_registry_event/events',
-       'timeout' => '500ms',
-       'threshold' => 5,
-       'backoff' => '1s',
-       'headers' => {
-         'Authorization' => ['<replace_with_a_secret_token>']
-       }
-     }
-   ]
-   ```
-
-   NOTE:
-   Replace `<example.com>` with the `external_url` defined in your primary site's `/etc/gitlab/gitlab.rb` file, and
-   replace `<replace_with_a_secret_token>` with a case sensitive alphanumeric string
-   that starts with a letter. You can generate one with `< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32 | sed "s/^[0-9]*//"; echo`
-
-   NOTE:
-   If you use an external Registry (not the one integrated with GitLab), you must add
-   these settings to its configuration yourself. In this case, you also have to specify
-   notification secret in `registry.notification_secret` section of
-   `/etc/gitlab/gitlab.rb` file.
-
-   NOTE:
-   If you use GitLab HA, you also have to specify
-   the notification secret in `registry.notification_secret` section of
-   `/etc/gitlab/gitlab.rb` file for every web node.
-
-1. Reconfigure the **primary** node for the change to take effect:
-
-   ```shell
-   gitlab-ctl reconfigure
-   ```
-
-### Configure **secondary** site
-
-Make sure you have Container Registry set up and working on
-the **secondary** site before following the next steps.
-
-The following steps should be done on each **secondary** site you're
-expecting to see the container images replicated.
-
-Because we need to allow the **secondary** site to communicate securely with
-the **primary** site Container Registry, we need to have a single key
-pair for all the sites. The **secondary** site uses this key to
-generate a short-lived JWT that is pull-only-capable to access the
-**primary** site Container Registry.
-
-For each application and Sidekiq node on the **secondary** site:
-
-1. SSH into the node and login as the `root` user:
-
-   ```shell
-   sudo -i
-   ```
-
-1. Copy `/var/opt/gitlab/gitlab-rails/etc/gitlab-registry.key` from the **primary** to the node.
-
-1. Edit `/etc/gitlab/gitlab.rb` and add:
-
-   ```ruby
-   gitlab_rails['geo_registry_replication_enabled'] = true
-
-   # Primary registry's hostname and port, it will be used by
-   # the secondary node to directly communicate to primary registry
-   gitlab_rails['geo_registry_replication_primary_api_url'] = 'https://primary.example.com:5050/'
-   ```
-
-1. Reconfigure the node for the change to take effect:
-
-   ```shell
-   gitlab-ctl reconfigure
-   ```
-
-### Verify replication
-
-To verify Container Registry replication is working, on the **secondary** site:
-
-1. On the top bar, select **Menu > Admin**.
-1. On the left sidebar, select **Geo > Nodes**.
-   The initial replication, or "backfill", is probably still in progress.
-
-You can monitor the synchronization process on each Geo site from the **primary** site's **Geo Nodes** dashboard in your browser.
+<!-- This redirect file can be deleted after <2022-10-29>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

doc/administration/geo/replication/faq.md

@@ -65,9 +65,9 @@ connectivity between your sites, your hardware, and so on.
 
 That's totally fine. We use HTTP(s) to fetch repository changes from the **primary** site to all **secondary** sites.
 
-## Is this possible to set up a Docker Registry for a **secondary** site that mirrors the one on the **primary** site?
+## Is this possible to set up a Container Registry for a **secondary** site that mirrors the one on the **primary** site?
 
-Yes. See [Docker Registry for a **secondary** site](docker_registry.md).
+Yes. See [Container Registry for a **secondary** site](container_registry.md).
 
 ## Can you log in to a secondary site?
 

doc/architecture/blueprints/container_registry_metadata_database/index.md

@@ -78,7 +78,7 @@ The single entrypoint for the registry is the [HTTP API](https://gitlab.com/gitl
 | Operation                                                    | UI                 | Background               | Observations                                                 |
 | ------------------------------------------------------------ | ------------------ | ------------------------ | ------------------------------------------------------------ |
 | [Check API version](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/spec/api.md#api-version-check) | **{check-circle}** Yes | **{check-circle}** Yes | Used globally to ensure that the registry supports the Docker Distribution V2 API, as well as for identifying whether GitLab Rails is talking to the GitLab Container Registry or a third-party one (used to toggle features only available in the former). |
-| [List repository tags](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/spec/api.md#listing-image-tags) | **{check-circle}** Yes | **{check-circle}** Yes | Used to list and show tags in the UI. Used to list tags in the background for [cleanup policies](../../../user/packages/container_registry/reduce_container_registry_storage.md#cleanup-policy) and [Geo replication](../../../administration/geo/replication/docker_registry.md). |
+| [List repository tags](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/spec/api.md#listing-image-tags) | **{check-circle}** Yes | **{check-circle}** Yes | Used to list and show tags in the UI. Used to list tags in the background for [cleanup policies](../../../user/packages/container_registry/reduce_container_registry_storage.md#cleanup-policy) and [Geo replication](../../../administration/geo/replication/container_registry.md). |
 | [Check if manifest exists](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/spec/api.md#existing-manifests) | **{check-circle}** Yes | **{dotted-circle}** No | Used to get the digest of a manifest by tag. This is then used to pull the manifest and show the tag details in the UI. |
 | [Pull manifest](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/spec/api.md#pulling-an-image-manifest) | **{check-circle}** Yes | **{dotted-circle}** No | Used to show the image size and the manifest digest in the tag details UI. |
 | [Pull blob](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/spec/api.md#pulling-a-layer) | **{check-circle}** Yes | **{dotted-circle}** No | Used to show the configuration digest and the creation date in the tag details UI. |