Merge branch 'selhorn-note-that-3' into 'master'

Docs: removed 'note that' phrase

See merge request gitlab-org/gitlab!67076

doc/administration/geo/disaster_recovery/background_verification.md

@@ -161,7 +161,7 @@ If the **primary** and **secondary** nodes have a checksum verification mismatch
       ![Project administration page](img/checksum-differences-admin-project-page.png)
 
 1. Go to the project's repository directory on both **primary** and **secondary** nodes
-   (the path is usually `/var/opt/gitlab/git-data/repositories`). Note that if `git_data_dirs`
+   (the path is usually `/var/opt/gitlab/git-data/repositories`). If `git_data_dirs`
    is customized, check the directory layout on your server to be sure:
 
    ```shell

doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md

@@ -94,7 +94,7 @@ follow these steps to avoid unnecessary data loss:
 
 1. Until a [read-only mode](https://gitlab.com/gitlab-org/gitlab/-/issues/14609)
    is implemented, updates must be prevented from happening manually to the
-   **primary**. Note that your **secondary** node still needs read-only
+   **primary**. Your **secondary** node still needs read-only
    access to the **primary** node during the maintenance window:
 
    1. At the scheduled time, using your cloud provider or your node's firewall, block

doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md

@@ -79,7 +79,7 @@ follow these steps to avoid unnecessary data loss:
 
 1. Until a [read-only mode](https://gitlab.com/gitlab-org/gitlab/-/issues/14609)
    is implemented, updates must be prevented from happening manually to the
-   **primary**. Note that your **secondary** node still needs read-only
+   **primary**. Your **secondary** node still needs read-only
    access to the **primary** node during the maintenance window:
 
    1. At the scheduled time, using your cloud provider or your node's firewall, block

doc/administration/geo/index.md

@@ -101,12 +101,12 @@ From the perspective of a user performing Git operations:
 - The **primary** site behaves as a full read-write GitLab instance.
 - **Secondary** sites are read-only but proxy Git push operations to the **primary** site. This makes **secondary** sites appear to support push operations themselves.
 
-To simplify the diagram, some necessary components are omitted. Note that:
+To simplify the diagram, some necessary components are omitted.
 
 - Git over SSH requires [`gitlab-shell`](https://gitlab.com/gitlab-org/gitlab-shell) and OpenSSH.
 - Git over HTTPS required [`gitlab-workhorse`](https://gitlab.com/gitlab-org/gitlab-workhorse).
 
-Note that a **secondary** site needs two different PostgreSQL databases:
+A **secondary** site needs two different PostgreSQL databases:
 
 - A read-only database instance that streams data from the main GitLab database.
 - [Another database instance](#geo-tracking-database) used internally by the **secondary** site to record what data has been replicated.

doc/administration/geo/replication/configuration.md

@@ -286,9 +286,9 @@ The two most obvious issues that can become apparent in the dashboard are:
    - You are using a custom certificate or custom CA (see the [troubleshooting document](troubleshooting.md)).
    - The instance is firewalled (check your firewall rules).
 
-Please note that disabling a **secondary** site stops the synchronization process.
+Disabling a **secondary** site stops the synchronization process.
 
-Please note that if `git_data_dirs` is customized on the **primary** site for multiple
+If `git_data_dirs` is customized on the **primary** site for multiple
 repository shards you must duplicate the same configuration on each **secondary** site.
 
 Point your users to the [Using a Geo Site guide](usage.md).

doc/administration/geo/replication/datatypes.md

@@ -204,7 +204,7 @@ successfully, you must replicate their data using some other means.
 |[Server-side Git hooks](../../server_hooks.md)                                                                 | [No](https://gitlab.com/groups/gitlab-org/-/epics/1867)                 | No                                                                      | No                                                                            |       |
 |[Elasticsearch integration](../../../integration/elasticsearch.md)                                             | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/1186)                | No                                                                      | No                                                                            |       |
 |[GitLab Pages](../../pages/index.md)                                                                           | [No](https://gitlab.com/groups/gitlab-org/-/epics/589)                  | No                                                                      | Via Object Storage provider if supported. **No** native Geo support (Beta).                                                                            |       |
-|[Dependency proxy images](../../../user/packages/dependency_proxy/index.md)                                    | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/259694)              | No                                                                      | No                                                                            | Blocked on [Geo: Secondary Mimicry](https://gitlab.com/groups/gitlab-org/-/epics/1528). Note that replication of this cache is not needed for Disaster Recovery purposes because it can be recreated from external sources. |
+|[Dependency proxy images](../../../user/packages/dependency_proxy/index.md)                                    | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/259694)              | No                                                                      | No                                                                            | Blocked on [Geo: Secondary Mimicry](https://gitlab.com/groups/gitlab-org/-/epics/1528). Replication of this cache is not needed for Disaster Recovery purposes because it can be recreated from external sources. |
 |[Vulnerability Export](../../../user/application_security/vulnerability_report/#export-vulnerability-details)  | [Not planned](https://gitlab.com/groups/gitlab-org/-/epics/3111)        | No                                                                      |  | Not planned because they are ephemeral and sensitive. They can be regenerated on demand. |
 
 #### Limitation of verification for files in Object Storage

doc/administration/geo/replication/multiple_servers.md

@@ -154,7 +154,7 @@ the **primary** database. Use the following as a guide.
 1. Generate an MD5 hash of the desired password for the database user that the
    GitLab application uses to access the read-replica database:
 
-   Note that the username (`gitlab` by default) is incorporated into the hash.
+   The username (`gitlab` by default) is incorporated into the hash.
 
    ```shell
    gitlab-ctl pg-password-md5 gitlab
@@ -203,7 +203,7 @@ the **primary** database. Use the following as a guide.
    geo_postgresql['enable'] = false
 
    ##
-   ## Disable all other services that aren't needed. Note that we had to enable
+   ## Disable all other services that aren't needed. We had to enable
    ## geo_secondary_role to cause some configuration changes to postgresql, but
    ## the role enables single-node services by default.
    ##
@@ -241,7 +241,7 @@ Configure the tracking database.
 1. Generate an MD5 hash of the desired password for the database user that the
    GitLab application uses to access the tracking database:
 
-   Note that the username (`gitlab_geo` by default) is incorporated into the
+   The username (`gitlab_geo` by default) is incorporated into the
    hash.
 
    ```shell

doc/administration/geo/setup/external_database.md

@@ -242,7 +242,7 @@ the tracking database on port 5432.
 
 1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
 
-1. The reconfigure should automatically create the database. If needed, you can perform this task manually. Note that this task (whether run by itself or during reconfigure) requires the database user to be a superuser.
+1. The reconfigure should automatically create the database. If needed, you can perform this task manually. This task (whether run by itself or during reconfigure) requires the database user to be a superuser.
 
    ```shell
    gitlab-rake geo:db:create

doc/administration/gitaly/configure_gitaly.md

@@ -952,7 +952,7 @@ result as you did at the start. For example:
 {enforced="true",status="ok"}  4424.985419441742
 ```
 
-Note that `enforced="true"` means that authentication is being enforced.
+`enforced="true"` means that authentication is being enforced.
 
 ## Pack-objects cache **(FREE SELF)**
 
@@ -1076,7 +1076,7 @@ cache hit and the average amount of storage used by cache files.
 Entries older than `max_age` get evicted from the in-memory metadata
 store, and deleted from disk.
 
-Note that eviction does not interfere with ongoing requests, so it is OK
+Eviction does not interfere with ongoing requests, so it is OK
 for `max_age` to be less than the time it takes to do a fetch over a
 slow connection. This is because Unix filesystems do not truly delete
 a file until all processes that are reading the deleted file have

doc/administration/gitaly/praefect.md

@@ -195,7 +195,7 @@ instructions only work on Omnibus-provided PostgreSQL:
    ```
 
    Replace `<PRAEFECT_SQL_PASSWORD_HASH>` with the hash of the password you generated in the
-   preparation step. Note that it is prefixed with `md5` literal.
+   preparation step. It is prefixed with `md5` literal.
 
 1. The PgBouncer that is shipped with Omnibus is configured to use [`auth_query`](https://www.pgbouncer.org/config.html#generic-settings)
    and uses `pg_shadow_lookup` function. You need to create this function in `praefect_production`

doc/administration/monitoring/performance/grafana_configuration.md

@@ -80,7 +80,7 @@ GitLab displays your link in the **Menu > Admin > Monitoring > Metrics Dashboard
 
 When setting up Grafana through the process above, no scope shows in the screen at
 **Menu >** **{admin}** **Admin > Applications > GitLab Grafana**. However, the `read_user` scope is
-required and is provided to the application automatically. Note that setting any scope other than
+required and is provided to the application automatically. Setting any scope other than
 `read_user` without also including `read_user` leads to this error when you try to log in using
 GitLab as the OAuth provider:
 

doc/administration/operations/fast_ssh_key_lookup.md

@@ -48,7 +48,7 @@ lookups via database lookup.
 
 As part of [setting up Geo](../geo/index.md#setup-instructions),
 you are required to follow the steps outlined below for both the primary and
-secondary nodes, but note that the `Write to "authorized keys" file` checkbox
+secondary nodes, but the `Write to "authorized keys" file` checkbox
 only needs to be unchecked on the primary node since it is reflected
 automatically on the secondary if database replication is working.
 

doc/administration/pages/index.md

@@ -41,7 +41,7 @@ which you can set it up:
    the Pages daemon is installed, so you must share it through the network.
 - Run the Pages daemon in the same server as GitLab, listening on the same IP
    but on different ports. In that case, you must proxy the traffic with
-   a load balancer. If you choose that route note that you should use TCP load
+   a load balancer. If you choose that route, you should use TCP load
    balancing for HTTPS. If you use TLS-termination (HTTPS-load balancing), the
    pages can't be served with user-provided certificates. For
    HTTP it's OK to use HTTP or TCP load balancing.

doc/administration/pages/source.md

@@ -41,7 +41,7 @@ which you can set it up:
    the Pages daemon is installed, so you must share it through the network.
 1. Run the Pages daemon in the same server as GitLab, listening on the same IP
    but on different ports. In that case, you must proxy the traffic with
-   a load balancer. If you choose that route, note that you should use TCP load
+   a load balancer. If you choose that route, you should use TCP load
    balancing for HTTPS. If you use TLS-termination (HTTPS-load balancing), the
    pages aren't able to be served with user-provided certificates. For
    HTTP, it's OK to use HTTP or TCP load balancing.

doc/administration/postgresql/replication_and_failover.md

@@ -889,7 +889,7 @@ with:
 sudo gitlab-ctl stop patroni
 ```
 
-Note that stopping or restarting Patroni service on the leader node will trigger the automatic failover. If you
+Stopping or restarting Patroni service on the leader node will trigger the automatic failover. If you
 want to signal Patroni to reload its configuration or restart PostgreSQL process without triggering the failover, you
 must use the `reload` or `restart` sub-commands of `gitlab-ctl patroni` instead. These two sub-commands are wrappers of
 the same `patronictl` commands.
@@ -1015,7 +1015,7 @@ Here are a few key facts that you must consider before upgrading PostgreSQL:
 - Upgrading PostgreSQL creates a new data directory with a new control data. From Patroni's perspective
   this is a new cluster that needs to be bootstrapped again. Therefore, as part of the upgrade procedure,
   the cluster state (stored in Consul) is wiped out. Once the upgrade is completed, Patroni
-  bootstraps a new cluster. **Note that this changes your _cluster ID_**.
+  bootstraps a new cluster. **This changes your _cluster ID_**.
 
 - The procedures for upgrading leader and replicas are not the same. That is why it is important to use the
   right procedure on each node.

doc/administration/raketasks/check.md

@@ -21,7 +21,7 @@ There are 3 things that are checked to determine integrity.
 1. Check for `config.lock` in the repository directory.
 1. Check for any branch/references lock files in `refs/heads`.
 
-It's important to note that the existence of `config.lock` or reference locks
+The existence of `config.lock` or reference locks
 alone do not necessarily indicate a problem. Lock files are routinely created
 and removed as Git and GitLab perform operations on the repository. They serve
 to prevent data integrity issues. However, if a Git operation is interrupted these

doc/administration/redis/replication_and_failover.md

@@ -683,8 +683,6 @@ To make this work with Sentinel:
    ]
    ```
 
-   Note that:
-
    - Redis URLs should be in the format: `redis://:PASSWORD@SENTINEL_PRIMARY_NAME`, where:
      - `PASSWORD` is the plaintext password for the Redis instance.
      - `SENTINEL_PRIMARY_NAME` is the Sentinel primary name set with `redis['master_name']`,
@@ -731,7 +729,7 @@ redis_master_role['enable'] = true # enable only one of them
 redis_replica_role['enable'] = true # enable only one of them
 
 # When Redis primary or Replica role are enabled, the following services are
-# enabled/disabled. Note that if Redis and Sentinel roles are combined, both
+# enabled/disabled. If Redis and Sentinel roles are combined, both
 # services are enabled.
 
 # The following services are disabled

doc/administration/reference_architectures/10k_users.md

@@ -345,7 +345,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`.
 The Internal Load Balancer is used to balance any internal connections the GitLab environment requires
 such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster).
 
-Note that it's a separate node from the External Load Balancer and shouldn't have any access externally.
+It's a separate node from the External Load Balancer and shouldn't have any access externally.
 
 The following IP will be used as an example:
 

doc/administration/reference_architectures/25k_users.md

@@ -347,7 +347,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`.
 The Internal Load Balancer is used to balance any internal connections the GitLab environment requires
 such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster).
 
-Note that it's a separate node from the External Load Balancer and shouldn't have any access externally.
+It's a separate node from the External Load Balancer and shouldn't have any access externally.
 
 The following IP will be used as an example:
 

doc/administration/reference_architectures/3k_users.md

@@ -346,7 +346,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`.
 The Internal Load Balancer is used to balance any internal connections the GitLab environment requires
 such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster).
 
-Note that it's a separate node from the External Load Balancer and shouldn't have any access externally.
+It's a separate node from the External Load Balancer and shouldn't have any access externally.
 
 The following IP will be used as an example:
 
@@ -2086,7 +2086,7 @@ but with smaller performance requirements, several modifications can be consider
 - Combining select nodes: Some nodes can be combined to reduce complexity at the cost of some performance:
   - GitLab Rails and Sidekiq: Sidekiq nodes can be removed and the component instead enabled on the GitLab Rails nodes.
   - PostgreSQL and PgBouncer: PgBouncer nodes can be removed and the component instead enabled on PostgreSQL with the Internal Load Balancer pointing to them instead.
-- Reducing the node counts: Some node types do not need consensus and can run with fewer nodes (but more than one for redundancy). Note that this will also lead to reduced performance.
+- Reducing the node counts: Some node types do not need consensus and can run with fewer nodes (but more than one for redundancy). This will also lead to reduced performance.
   - GitLab Rails and Sidekiq: Stateless services don't have a minimum node count. Two are enough for redundancy.
   - Gitaly and Praefect: A quorum is not strictly necessary. Two Gitaly nodes and two Praefect nodes are enough for redundancy.
 - Running select components in reputable Cloud PaaS solutions: Select components of the GitLab setup can instead be run on Cloud Provider PaaS solutions. By doing this, additional dependent components can also be removed:

doc/administration/reference_architectures/50k_users.md

@@ -354,7 +354,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`.
 The Internal Load Balancer is used to balance any internal connections the GitLab environment requires
 such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster).
 
-Note that it's a separate node from the External Load Balancer and shouldn't have any access externally.
+It's a separate node from the External Load Balancer and shouldn't have any access externally.
 
 The following IP will be used as an example:
 

doc/administration/reference_architectures/5k_users.md

@@ -338,7 +338,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`.
 The Internal Load Balancer is used to balance any internal connections the GitLab environment requires
 such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configure-praefect) (Gitaly Cluster).
 
-Note that it's a separate node from the External Load Balancer and shouldn't have any access externally.
+It's a separate node from the External Load Balancer and shouldn't have any access externally.
 
 The following IP will be used as an example:
 

doc/administration/troubleshooting/debug.md

@@ -45,7 +45,7 @@ session by running:
 ActiveRecord::Base.connection.execute('SET statement_timeout TO 0')
 ```
 
-Note that this change only affects the current Rails console session and will
+This change only affects the current Rails console session and will
 not be persisted in the GitLab production environment or in the next Rails
 console session.
 
@@ -213,7 +213,7 @@ downtime. Otherwise skip to the next section.
    exit
    ```
 
-Note that if the Puma process terminates before you are able to run these
+If the Puma process terminates before you are able to run these
 commands, GDB will report an error. To buy more time, you can always raise the
 Puma worker timeout. For omnibus users, you can edit `/etc/gitlab/gitlab.rb` and
 increase it from 60 seconds to 600: