Fix up the docs warning detected by the vale latin term rule

doc/administration/geo/replication/faq.md

@@ -23,7 +23,7 @@ For each project to sync:
 
 1. Geo issues a `git fetch geo --mirror` to get the latest information from the **primary** site.
    If there are no changes, the sync is fast. Otherwise, it has to pull the latest commits.
-1. The **secondary** site updates the tracking database to store the fact that it has synced projects A, B, C, etc.
+1. The **secondary** site updates the tracking database to store the fact that it has synced projects A, B, C, and so on.
 1. Repeat until all projects are synced.
 
 When someone pushes a commit to the **primary** site, it generates an event in the GitLab database that the repository has changed.
@@ -47,7 +47,7 @@ Read the documentation for [Disaster Recovery](../disaster_recovery/index.md).
 
 We currently replicate project repositories, LFS objects, generated
 attachments and avatars, and the whole database. This means user accounts,
-issues, merge requests, groups, project data, etc., will be available for
+issues, merge requests, groups, project data, and so on, will be available for
 query.
 
 ## Can I `git push` to a **secondary** site?
@@ -58,7 +58,7 @@ Yes! Pushing directly to a **secondary** site (for both HTTP and SSH, including
 
 All replication operations are asynchronous and are queued to be dispatched. Therefore, it depends on a lot of
 factors including the amount of traffic, how big your commit is, the
-connectivity between your sites, your hardware, etc.
+connectivity between your sites, your hardware, and so on.
 
 ## What if the SSH server runs at a different port?
 

doc/administration/geo/replication/location_aware_git_url.md

@@ -88,7 +88,7 @@ routing configurations.
 
    ![Created policy record](img/single_git_created_policy_record.png)
 
-You have successfully set up a single host, e.g. `git.example.com` which
+You have successfully set up a single host, for example, `git.example.com` which
 distributes traffic to your Geo sites by geolocation!
 
 ## Configure Git clone URLs to use the special Git URL

doc/administration/geo/replication/security_review.md

@@ -60,7 +60,7 @@ from [owasp.org](https://owasp.org/).
   access), but is constrained to read-only activities. The principal use case is
   envisioned to be cloning Git repositories from the **secondary** site in favor of the
   **primary** site, but end-users may use the GitLab web interface to view projects,
-  issues, merge requests, snippets, etc.
+  issues, merge requests, snippets, and so on.
 
 ### What security expectations do the end‐users have?
 
@@ -203,7 +203,7 @@ from [owasp.org](https://owasp.org/).
 ### What data entry paths does the application support?
 
 - Data is entered via the web application exposed by GitLab itself. Some data is
-  also entered using system administration commands on the GitLab servers (e.g.,
+  also entered using system administration commands on the GitLab servers (for example
   `gitlab-ctl set-primary-node`).
 - **Secondary** sites also receive inputs via PostgreSQL streaming replication from the **primary** site.
 
@@ -247,7 +247,7 @@ from [owasp.org](https://owasp.org/).
 ### What encryption requirements have been defined for data in transit - including transmission over WAN, LAN, SecureFTP, or publicly accessible protocols such as http: and https:?
 
 - Data must have the option to be encrypted in transit, and be secure against
-  both passive and active attack (e.g., MITM attacks should not be possible).
+  both passive and active attack (for example, MITM attacks should not be possible).
 
 ## Access
 

doc/administration/geo/replication/troubleshooting.md

@@ -327,7 +327,7 @@ Slots where `active` is `f` are not active.
 - When this slot should be active, because you have a **secondary** node configured using that slot,
   log in to that **secondary** node and check the PostgreSQL logs why the replication is not running.
 
-- If you are no longer using the slot (e.g. you no longer have Geo enabled), you can remove it with in the
+- If you are no longer using the slot (for example, you no longer have Geo enabled), you can remove it with in the
   PostgreSQL console session:
 
   ```sql
@@ -378,7 +378,7 @@ This happens on wrongly-formatted addresses in `postgresql['md5_auth_cidr_addres
 ```
 
 To fix this, update the IP addresses in `/etc/gitlab/gitlab.rb` under `postgresql['md5_auth_cidr_addresses']`
-to respect the CIDR format (i.e. `1.2.3.4/32`).
+to respect the CIDR format (that is, `1.2.3.4/32`).
 
 ### Message: `LOG:  invalid IP mask "md5": Name or service not known`
 
@@ -390,7 +390,7 @@ This happens when you have added IP addresses without a subnet mask in `postgres
 ```
 
 To fix this, add the subnet mask in `/etc/gitlab/gitlab.rb` under `postgresql['md5_auth_cidr_addresses']`
-to respect the CIDR format (i.e. `1.2.3.4/32`).
+to respect the CIDR format (that is, `1.2.3.4/32`).
 
 ### Message: `Found data in the gitlabhq_production database!` when running `gitlab-ctl replicate-geo-database`
 
@@ -653,7 +653,7 @@ promotion.
 #### If you are promoting a Geo secondary site running on multiple servers
 
 `gitlab-ctl promotion-preflight-checks` will fail due to the existence of
-`failed` rows in the `geo_design_registry` table. Use the 
+`failed` rows in the `geo_design_registry` table. Use the
 [previous snippet](#design-repository-failures-on-mirrored-projects-and-project-imports) to
 determine the actual replication status of Design repositories.
 
@@ -864,7 +864,7 @@ PostgreSQL instances:
 
 The most common problems that prevent the database from replicating correctly are:
 
-- **Secondary** nodes cannot reach the **primary** node. Check credentials, firewall rules, etc.
+- **Secondary** nodes cannot reach the **primary** node. Check credentials, firewall rules, and so on.
 - SSL certificate problems. Make sure you copied `/etc/gitlab/gitlab-secrets.json` from the **primary** node.
 - Database storage disk is full.
 - Database replication slot is misconfigured.

doc/administration/geo/setup/database.md

@@ -462,10 +462,10 @@ data before running `pg_basebackup`.
 
    - If PostgreSQL is listening on a non-standard port, add `--port=` as well.
    - If your database is too large to be transferred in 30 minutes, you need
-     to increase the timeout, e.g., `--backup-timeout=3600` if you expect the
+     to increase the timeout, for example, `--backup-timeout=3600` if you expect the
      initial replication to take under an hour.
    - Pass `--sslmode=disable` to skip PostgreSQL TLS authentication altogether
-     (e.g., you know the network path is secure, or you are using a site-to-site
+     (for example, you know the network path is secure, or you are using a site-to-site
      VPN). This is **not** safe over the public Internet!
    - You can read more details about each `sslmode` in the
      [PostgreSQL documentation](https://www.postgresql.org/docs/12/libpq-ssl.html#LIBPQ-SSL-PROTECTION);

doc/administration/geo/setup/external_database.md

@@ -57,7 +57,7 @@ developed and tested. We aim to be compatible with most external
 
 To set up an external database, you can either:
 
-- Set up [streaming replication](https://www.postgresql.org/docs/12/warm-standby.html#STREAMING-REPLICATION-SLOTS) yourself (for example AWS RDS, bare metal not managed by Omnibus, etc.).
+- Set up [streaming replication](https://www.postgresql.org/docs/12/warm-standby.html#STREAMING-REPLICATION-SLOTS) yourself (for example AWS RDS, bare metal not managed by Omnibus, and so on).
 - Perform the Omnibus configuration manually as follows.
 
 #### Leverage your cloud provider's tools to replicate the primary database

doc/administration/maintenance_mode/index.md

@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2149) in GitLab Premium 13.9.
 
-Maintenance Mode allows administrators to reduce write operations to a minimum while maintenance tasks are performed. The main goal is to block all external actions that change the internal state, including the PostgreSQL database, but especially files, Git repositories, Container repositories, etc.
+Maintenance Mode allows administrators to reduce write operations to a minimum while maintenance tasks are performed. The main goal is to block all external actions that change the internal state, including the PostgreSQL database, but especially files, Git repositories, Container repositories, and so on.
 
 Once Maintenance Mode is enabled, in-progress actions finish relatively quickly since no new actions are coming in, and internal state changes are minimal.
 In that state, various maintenance tasks are easier, and services can be stopped completely or be

doc/administration/monitoring/prometheus/gitlab_metrics.md

@@ -344,7 +344,7 @@ These client metrics are meant to complement Redis server metrics.
 These metrics are broken down per [Redis
 instance](https://docs.gitlab.com/omnibus/settings/redis.html#running-with-multiple-redis-instances).
 These metrics all have a `storage` label which indicates the Redis
-instance (`cache`, `shared_state` etc.).
+instance (`cache`, `shared_state`, and so on).
 
 | Metric                            | Type    | Since | Description |
 |:--------------------------------- |:------- |:----- |:----------- |

doc/administration/nfs.md

@@ -10,7 +10,7 @@ type: reference
 NFS can be used as an alternative for object storage but this isn't typically
 recommended for performance reasons.
 
-For data objects such as LFS, Uploads, Artifacts, etc., an [Object Storage service](object_storage.md)
+For data objects such as LFS, Uploads, Artifacts, and so on, an [Object Storage service](object_storage.md)
 is recommended over NFS where possible, due to better performance.
 
 File system performance can impact overall GitLab performance, especially for

doc/administration/operations/sidekiq_memory_killer.md

@@ -25,7 +25,7 @@ minute of delay for incoming background jobs.
 
 Some background jobs rely on long-running external processes. To ensure these
 are cleanly terminated when Sidekiq is restarted, each Sidekiq process should be
-run as a process group leader (e.g., using `chpst -P`). If using Omnibus or the
+run as a process group leader (for example, using `chpst -P`). If using Omnibus or the
 `bin/background_jobs` script with `runit` installed, this is handled for you.
 
 ## Configuring the MemoryKiller
@@ -80,4 +80,4 @@ The MemoryKiller is controlled using environment variables.
   If the process hard shutdown/restart is not performed by Sidekiq,
   the Sidekiq process is forcefully terminated after
   `Sidekiq.options[:timeout] + 2` seconds. An external supervision mechanism
-  (e.g. runit) must restart Sidekiq afterwards.
+  (for example, runit) must restart Sidekiq afterwards.

doc/administration/operations/ssh_certificates.md

@@ -41,11 +41,11 @@ uploading user SSH keys to GitLab entirely.
 How to fully set up SSH certificates is outside the scope of this
 document. See [OpenSSH's
 `PROTOCOL.certkeys`](https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.certkeys?annotate=HEAD)
-for how it works, and e.g. [RedHat's documentation about
+for how it works, for example [RedHat's documentation about
 it](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication).
 
 We assume that you already have SSH certificates set up, and have
-added the `TrustedUserCAKeys` of your CA to your `sshd_config`, e.g.:
+added the `TrustedUserCAKeys` of your CA to your `sshd_config`, for example:
 
 ```plaintext
 TrustedUserCAKeys /etc/security/mycompany_user_ca.pub
@@ -58,7 +58,7 @@ used for GitLab consider putting this in the `Match User git` section
 (described below).
 
 The SSH certificates being issued by that CA **MUST** have a "key ID"
-corresponding to that user's username on GitLab, e.g. (some output
+corresponding to that user's username on GitLab, for example (some output
 omitted for brevity):
 
 ```shell
@@ -77,7 +77,7 @@ $ ssh-add -L | grep cert | ssh-keygen -L -f -
         [...]
 ```
 
-Technically that's not strictly true, e.g. it could be
+Technically that's not strictly true, for example, it could be
 `prod-aearnfjord` if it's a SSH certificate you'd normally log in to
 servers as the `prod-aearnfjord` user, but then you must specify your
 own `AuthorizedPrincipalsCommand` to do that mapping instead of using
@@ -107,13 +107,13 @@ command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell username-{KE
 ```
 
 Where `{KEY_ID}` is the `%i` argument passed to the script
-(e.g. `aeanfjord`), and `{PRINCIPAL}` is the principal passed to it
-(e.g. `sshUsers`).
+(for example, `aeanfjord`), and `{PRINCIPAL}` is the principal passed to it
+(for example, `sshUsers`).
 
 You need to customize the `sshUsers` part of that. It should be
 some principal that's guaranteed to be part of the key for all users
 who can log in to GitLab, or you must provide a list of principals,
-one of which is present for the user, e.g.:
+one of which is present for the user, for example:
 
 ```plaintext
     [...]
@@ -131,7 +131,7 @@ principal is some "group" that's allowed to log into that
 server. However with GitLab it's only used to appease OpenSSH's
 requirement for it, we effectively only care about the "key ID" being
 correct. Once that's extracted GitLab enforces its own ACLs for
-that user (e.g. what projects the user can access).
+that user (for example, what projects the user can access).
 
 So it's OK to e.g. be overly generous in what you accept, since if the
 user e.g. has no access to GitLab at all it just errors out with a