From e61610484016363305caf82680338ffc27c93e96 Mon Sep 17 00:00:00 2001
From: feistel <6742251-feistel@users.noreply.gitlab.com>
Date: Tue, 14 Jun 2022 13:07:29 +0200
Subject: [PATCH] Fix more vale warnings
Related to group: Geo
---
doc/.vale/gitlab/Uppercase.yml | 1 +
.../geo/disaster_recovery/bring_primary_back.md | 4 ++--
.../geo/disaster_recovery/planned_failover.md | 4 ++--
doc/administration/geo/replication/faq.md | 8 ++++----
doc/administration/geo/replication/remove_geo_site.md | 2 +-
doc/administration/geo/replication/troubleshooting.md | 8 ++++----
doc/administration/geo/replication/tuning.md | 2 +-
.../geo/replication/upgrading_the_geo_sites.md | 2 +-
doc/administration/geo/replication/usage.md | 6 +++---
doc/administration/geo/setup/external_database.md | 4 ++--
doc/administration/geo/setup/index.md | 2 +-
doc/administration/raketasks/geo.md | 2 +-
doc/development/geo.md | 10 +++++-----
doc/development/geo/framework.md | 4 ++--
doc/raketasks/backup_restore.md | 10 +++++-----
15 files changed, 35 insertions(+), 34 deletions(-)
diff --git a/doc/.vale/gitlab/Uppercase.yml b/doc/.vale/gitlab/Uppercase.yml
index d7f4d75a01274..1616ca2663966 100644
--- a/doc/.vale/gitlab/Uppercase.yml
+++ b/doc/.vale/gitlab/Uppercase.yml
@@ -14,6 +14,7 @@ first: '\b([A-Z]{3,5})\b'
second: '(?:\b[A-Z][a-z]+ )+\(([A-Z]{3,5})\)'
# ... with the exception of these:
exceptions:
+ - ACL
- AJAX
- ANSI
- APAC
diff --git a/doc/administration/geo/disaster_recovery/bring_primary_back.md b/doc/administration/geo/disaster_recovery/bring_primary_back.md
index 4c0a46b3096ae..833b9a877e96a 100644
--- a/doc/administration/geo/disaster_recovery/bring_primary_back.md
+++ b/doc/administration/geo/disaster_recovery/bring_primary_back.md
@@ -18,8 +18,8 @@ If you have any doubts about the consistency of the data on this site, we recomm
## Configure the former **primary** site to be a **secondary** site
-Since the former **primary** site will be out of sync with the current **primary** site, the first step is to bring the former **primary** site up to date. Note, deletion of data stored on disk like
-repositories and uploads will not be replayed when bringing the former **primary** site back
+Since the former **primary** site is out of sync with the current **primary** site, the first step is to bring the former **primary** site up to date. Note, deletion of data stored on disk like
+repositories and uploads is not replayed when bringing the former **primary** site back
into sync, which may result in increased disk usage.
Alternatively, you can [set up a new **secondary** GitLab instance](../setup/index.md) to avoid this.
diff --git a/doc/administration/geo/disaster_recovery/planned_failover.md b/doc/administration/geo/disaster_recovery/planned_failover.md
index 711017fa4c5c3..7d8dd7d5d2a1d 100644
--- a/doc/administration/geo/disaster_recovery/planned_failover.md
+++ b/doc/administration/geo/disaster_recovery/planned_failover.md
@@ -143,7 +143,7 @@ If the **primary** site uses custom or self-signed TLS certificates to secure in
### Ensure Geo replication is up-to-date
-The maintenance window won't end until Geo replication and verification is
+The maintenance window does not end until Geo replication and verification is
completely finished. To keep the window as short as possible, you should
ensure these processes are close to 100% as possible during active use.
@@ -201,7 +201,7 @@ be disabled on the **primary** site:
## Finish replicating and verifying all data
NOTE:
-GitLab 13.9 through GitLab 14.3 are affected by a bug in which the Geo secondary site statuses will appear to stop updating and become unhealthy. For more information, see [Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](../replication/troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode).
+GitLab 13.9 through GitLab 14.3 are affected by a bug in which the Geo secondary site statuses appears to stop updating and become unhealthy. For more information, see [Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](../replication/troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode).
1. If you are manually replicating any data not managed by Geo, trigger the
final replication process now.
diff --git a/doc/administration/geo/replication/faq.md b/doc/administration/geo/replication/faq.md
index fd29310dea0f6..bdf1771e8a805 100644
--- a/doc/administration/geo/replication/faq.md
+++ b/doc/administration/geo/replication/faq.md
@@ -32,10 +32,10 @@ To ensure that problems with pipelines (for example, syncs failing too many time
the number of concurrent syncs falls below `repos_max_capacity` and there are no new projects waiting to be synced.
Geo also has a checksum feature which runs a SHA256 sum across all the Git references to the SHA values.
-If the refs don't match between the **primary** site and the **secondary** site, then the **secondary** site will mark that project as dirty and try to resync it.
+If the refs don't match between the **primary** site and the **secondary** site, then the **secondary** site marks that project as dirty and try to resync it.
So even if we have an outdated tracking database, the validation should activate and find discrepancies in the repository state and resync.
-## Can I use Geo in a disaster recovery situation?
+## Can you use Geo in a disaster recovery situation?
Yes, but there are limitations to what we replicate (see
[What data is replicated to a **secondary** site?](#what-data-is-replicated-to-a-secondary-site)).
@@ -46,7 +46,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, and so on, will be available for
+issues, merge requests, groups, project data, and so on, are available for
query.
For more details, see the [supported Geo data types](datatypes.md).
@@ -69,6 +69,6 @@ That's totally fine. We use HTTP(s) to fetch repository changes from the **prima
Yes. See [Docker Registry for a **secondary** site](docker_registry.md).
-## Can I login to a secondary site?
+## Can you login to a secondary site?
Yes, but secondary sites receive all authentication data (like user accounts and logins) from the primary instance. This means you are re-directed to the primary for authentication and then routed back.
diff --git a/doc/administration/geo/replication/remove_geo_site.md b/doc/administration/geo/replication/remove_geo_site.md
index e25b3421f50b7..0d6715a93b72d 100644
--- a/doc/administration/geo/replication/remove_geo_site.md
+++ b/doc/administration/geo/replication/remove_geo_site.md
@@ -44,7 +44,7 @@ Once GitLab has been uninstalled from each node on the **secondary** site, the r
```
NOTE:
- Using `gitlab-rails dbconsole` will not work, because managing replication slots requires superuser permissions.
+ Using `gitlab-rails dbconsole` does not work, because managing replication slots requires superuser permissions.
1. Find the name of the relevant replication slot. This is the slot that is specified with `--slot-name` when running the replicate command: `gitlab-ctl replicate-geo-database`.
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index 9b53ba86951aa..91bd3bd0273ff 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -398,7 +398,7 @@ where some queries never complete due to being canceled on every replication.
These long-running queries are
[planned to be removed in the future](https://gitlab.com/gitlab-org/gitlab/-/issues/34269),
but as a workaround, we recommend enabling
-[hot_standby_feedback](https://www.postgresql.org/docs/10/hot-standby.html#HOT-STANDBY-CONFLICT).
+[`hot_standby_feedback`](https://www.postgresql.org/docs/10/hot-standby.html#HOT-STANDBY-CONFLICT).
This increases the likelihood of bloat on the **primary** node as it prevents
`VACUUM` from removing recently-dead rows. However, it has been used
successfully in production on GitLab.com.
@@ -767,7 +767,7 @@ The appropriate action sometimes depends on the cause. For example, you can remo
In some cases, a file may be determined to be of low value, and so it may be worth deleting the record.
-Geo itself is an excellent mitigation for files missing on the primary. If a file disappears on the primary but it was already synced to the secondary, you can grab the secondary's file. In cases like this, the `File is not checksummable` error message will not occur on Geo secondary sites, and only the primary will log this error message.
+Geo itself is an excellent mitigation for files missing on the primary. If a file disappears on the primary but it was already synced to the secondary, you can grab the secondary's file. In cases like this, the `File is not checksummable` error message does not occur on Geo secondary sites, and only the primary logs this error message.
This problem is more likely to show up in Geo secondary sites which were set up long after the original GitLab site. In this case, Geo is only surfacing an existing problem.
@@ -1104,9 +1104,9 @@ If using a load balancer, ensure that the load balancer's URL is set as the `ext
### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode
-In GitLab 13.9 through GitLab 14.3, when [GitLab Maintenance Mode](../../maintenance_mode/index.md) is enabled, the status of Geo secondary sites will stop getting updated. After 10 minutes, the status changes to `Unhealthy`.
+In GitLab 13.9 through GitLab 14.3, when [GitLab Maintenance Mode](../../maintenance_mode/index.md) is enabled, the status of Geo secondary sites stops getting updated. After 10 minutes, the status changes to `Unhealthy`.
-Geo secondary sites will continue to replicate and verify data, and the secondary sites should still be usable. You can use the [Sync status Rake task](#sync-status-rake-task) to determine the actual status of a secondary site during Maintenance Mode.
+Geo secondary sites continue to replicate and verify data, and the secondary sites should still be usable. You can use the [Sync status Rake task](#sync-status-rake-task) to determine the actual status of a secondary site during Maintenance Mode.
This bug was [fixed in GitLab 14.4](https://gitlab.com/gitlab-org/gitlab/-/issues/292983).
diff --git a/doc/administration/geo/replication/tuning.md b/doc/administration/geo/replication/tuning.md
index 4888ff0022e0b..670459624f3a6 100644
--- a/doc/administration/geo/replication/tuning.md
+++ b/doc/administration/geo/replication/tuning.md
@@ -25,7 +25,7 @@ On the **primary** site:
- Container repositories synchronization concurrency limit
- Verification concurrency limit
-Increasing the concurrency values will increase the number of jobs that are scheduled.
+Increasing the concurrency values increases the number of jobs that are scheduled.
However, this may not lead to more downloads in parallel unless the number of
available Sidekiq threads is also increased. For example, if repository synchronization
concurrency is increased from 25 to 50, you may also want to increase the number
diff --git a/doc/administration/geo/replication/upgrading_the_geo_sites.md b/doc/administration/geo/replication/upgrading_the_geo_sites.md
index 8230ccf65f3e6..30961de038123 100644
--- a/doc/administration/geo/replication/upgrading_the_geo_sites.md
+++ b/doc/administration/geo/replication/upgrading_the_geo_sites.md
@@ -22,7 +22,7 @@ Upgrading Geo sites involves performing:
NOTE:
These general upgrade steps are not intended for multi-site deployments,
-and will cause downtime. If you want to avoid downtime, consider using
+and cause downtime. If you want to avoid downtime, consider using
[zero downtime upgrades](../../../update/zero_downtime.md#multi-node--ha-deployment-with-geo).
To upgrade the Geo sites when a new GitLab version is released, upgrade **primary**
diff --git a/doc/administration/geo/replication/usage.md b/doc/administration/geo/replication/usage.md
index 7a1cc116182dc..fe0e06e7ea472 100644
--- a/doc/administration/geo/replication/usage.md
+++ b/doc/administration/geo/replication/usage.md
@@ -11,9 +11,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
After you set up the [database replication and configure the Geo nodes](../index.md#setup-instructions), use your closest GitLab site as you would do with the primary one.
You can push directly to a **secondary** site (for both HTTP, SSH including
-Git LFS), and the request will be proxied to the primary site instead.
+Git LFS), and the request is proxied to the primary site instead.
-Example of the output you will see when pushing to a **secondary** site:
+Example of the output you see when pushing to a **secondary** site:
```shell
$ git push
@@ -31,7 +31,7 @@ If you're using HTTPS instead of [SSH](../../../user/ssh.md) to push to the seco
you can't store credentials in the URL like `user:password@URL`. Instead, you can use a
[`.netrc` file](https://www.gnu.org/software/inetutils/manual/html_node/The-_002enetrc-file.html)
for Unix-like operating systems or `_netrc` for Windows. In that case, the credentials
-will be stored as a plain text. If you're looking for a more secure way to store credentials,
+are stored as a plain text. If you're looking for a more secure way to store credentials,
you can use [Git Credential Storage](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage).
## Fetch Go modules from Geo secondary sites
diff --git a/doc/administration/geo/setup/external_database.md b/doc/administration/geo/setup/external_database.md
index ec0c17c15dfa3..7e8ffa829f95b 100644
--- a/doc/administration/geo/setup/external_database.md
+++ b/doc/administration/geo/setup/external_database.md
@@ -51,7 +51,7 @@ developed and tested. We aim to be compatible with most external
gitlab-ctl set-geo-primary-node
```
- This command will use your defined `external_url` in `/etc/gitlab/gitlab.rb`.
+ This command uses your defined `external_url` in `/etc/gitlab/gitlab.rb`.
### Configure the external database to be replicated
@@ -64,7 +64,7 @@ To set up an external database, you can either:
Given you have a primary node set up on AWS EC2 that uses RDS.
You can now just create a read-only replica in a different region and the
-replication process will be managed by AWS. Make sure you've set Network ACL, Subnet, and
+replication process is managed by AWS. Make sure you've set Network ACL (Access Control List), Subnet, and
Security Group according to your needs, so the secondary application node can access the database.
The following instructions detail how to create a read-only replica for common
diff --git a/doc/administration/geo/setup/index.md b/doc/administration/geo/setup/index.md
index 59748499a7e6b..f4c212937827d 100644
--- a/doc/administration/geo/setup/index.md
+++ b/doc/administration/geo/setup/index.md
@@ -19,7 +19,7 @@ The steps below should be followed in the order they appear. **Make sure the Git
If you installed GitLab using the Omnibus packages (highly recommended):
-1. [Install GitLab Enterprise Edition](https://about.gitlab.com/install/) on the nodes that will serve as the **secondary** site. Do not create an account or log in to the new **secondary** site. The **GitLab version must match** across primary and secondary sites.
+1. [Install GitLab Enterprise Edition](https://about.gitlab.com/install/) on the nodes that serve as the **secondary** site. Do not create an account or log in to the new **secondary** site. The **GitLab version must match** across primary and secondary sites.
1. [Add the GitLab License](../../../user/admin_area/license.md) on the **primary** site to unlock Geo. The license must be for [GitLab Premium](https://about.gitlab.com/pricing/) or higher.
1. [Set up the database replication](database.md) (`primary (read-write) <-> secondary (read-only)` topology).
1. [Configure fast lookup of authorized SSH keys in the database](../../operations/fast_ssh_key_lookup.md). This step is required and needs to be done on **both** the **primary** and **secondary** sites.
diff --git a/doc/administration/raketasks/geo.md b/doc/administration/raketasks/geo.md
index 1d3422d0d985f..5c6c99d099bf5 100644
--- a/doc/administration/raketasks/geo.md
+++ b/doc/administration/raketasks/geo.md
@@ -33,7 +33,7 @@ sudo -u git -H bundle exec rake geo:git:housekeeping:incremental_repack RAILS_EN
### Full Repack
This is equivalent of running `git repack -d -A --pack-kept-objects` on a
-_bare_ repository which will optionally, write a reachability bitmap index
+_bare_ repository which optionally, writes a reachability bitmap index
when this is enabled in GitLab.
**Omnibus Installation**
diff --git a/doc/development/geo.md b/doc/development/geo.md
index a44d3e9c01c38..18dffe42177b2 100644
--- a/doc/development/geo.md
+++ b/doc/development/geo.md
@@ -33,15 +33,15 @@ for new events and creates background jobs for each specific event type.
For example when a repository is updated, the Geo **primary** site creates
a Geo event with an associated repository updated event. The Geo Log Cursor daemon
-picks the event up and schedules a `Geo::ProjectSyncWorker` job which will
-use the `Geo::RepositorySyncService` and `Geo::WikiSyncService` classes
+picks the event up and schedules a `Geo::ProjectSyncWorker` job which
+uses the `Geo::RepositorySyncService` and `Geo::WikiSyncService` classes
to update the repository and the wiki respectively.
The Geo Log Cursor daemon can operate in High Availability mode automatically.
-The daemon will try to acquire a lock from time to time and once acquired, it
-will behave as the *active* daemon.
+The daemon tries to acquire a lock from time to time and once acquired, it
+behaves as the *active* daemon.
-Any additional running daemons on the same site, will be in standby
+Any additional running daemons on the same site, is in standby
mode, ready to resume work if the *active* daemon releases its lock.
We use the [`ExclusiveLease`](https://www.rubydoc.info/github/gitlabhq/gitlabhq/Gitlab/ExclusiveLease) lock type with a small TTL, that is renewed at every
diff --git a/doc/development/geo/framework.md b/doc/development/geo/framework.md
index 7738daee3bc55..18774b9b3fd64 100644
--- a/doc/development/geo/framework.md
+++ b/doc/development/geo/framework.md
@@ -59,7 +59,7 @@ naming conventions:
consume) events. It takes care of the communication between the
primary site (where events are produced) and the secondary site
(where events are consumed). The engineer who wants to incorporate
- Geo in their feature will use the API of replicators to make this
+ Geo in their feature uses the API of replicators to make this
happen.
- **Geo Domain-Specific Language**:
@@ -99,7 +99,7 @@ end
The class name should be unique. It also is tightly coupled to the
table name for the registry, so for this example the registry table
-will be `package_file_registry`.
+is `package_file_registry`.
For the different data types Geo supports there are different
strategies to include. Pick one that fits your needs.
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index 5b5878f63479b..d14263f660a8b 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -1015,9 +1015,9 @@ more of the following options:
- `BACKUP=timestamp_of_backup`: Required if more than one backup exists.
Read what the [backup timestamp is about](#backup-timestamp).
-- `force=yes`: Doesn't ask if the authorized_keys file should get regenerated,
+- `force=yes`: Doesn't ask if the `authorized_keys` file should get regenerated,
and assumes 'yes' for warning about database tables being removed,
- enabling the "Write to authorized_keys file" setting, and updating LDAP
+ enabling the `Write to authorized_keys file` setting, and updating LDAP
providers.
If you're restoring into directories that are mount points, you must ensure these directories are
@@ -1407,7 +1407,7 @@ There is an **experimental** script that attempts to automate this process in
## Back up and restore for installations using PgBouncer
-Do NOT back up or restore GitLab through a PgBouncer connection. These
+Do not back up or restore GitLab through a PgBouncer connection. These
tasks must [bypass PgBouncer and connect directly to the PostgreSQL primary database node](#bypassing-pgbouncer),
or they cause a GitLab outage.
@@ -1418,7 +1418,7 @@ following error message is shown:
ActiveRecord::StatementInvalid: PG::UndefinedTable
```
-Each time the GitLab backup runs, GitLab will start generating 500 errors and errors about missing
+Each time the GitLab backup runs, GitLab starts generating 500 errors and errors about missing
tables will [be logged by PostgreSQL](../administration/logs.md#postgresql-logs):
```plaintext
@@ -1480,7 +1480,7 @@ WARNING:
Avoid uncoordinated data processing by both the new and old servers, where multiple
servers could connect concurrently and process the same data. For example, when using
[incoming email](../administration/incoming_email.md), if both GitLab instances are
-processing email at the same time, then both instances will end up missing some data.
+processing email at the same time, then both instances miss some data.
This type of problem can occur with other services as well, such as a
[non-packaged database](https://docs.gitlab.com/omnibus/settings/database.html#using-a-non-packaged-postgresql-database-management-server),
a non-packaged Redis instance, or non-packaged Sidekiq.
--
GitLab