Add latest changes from gitlab-org/gitlab@master

.gitlab/issue_templates/Coding style proposal.md

@@ -11,6 +11,6 @@ Please describe the proposal and add a link to the source (for example, http://w
 
 /label ~"development guidelines"
 /label ~"Style decision"
-/label ~Documentation
+/label ~documentation
 
 /cc @gitlab-org/maintainers/rails-backend

.gitlab/issue_templates/Doc Review.md

@@ -17,4 +17,4 @@ Related issue(s):
 <!-- Any additional context, questions, or notes for the technical writer. -->
 
 
-/label ~Documentation ~docs-review
+/label ~documentation ~"Technical Writing"

.gitlab/issue_templates/Documentation.md

@@ -9,16 +9,6 @@
 * For information about documentation content and process, see
      https://docs.gitlab.com/ee/development/documentation/ -->
 
-<!-- Type of issue -->
-
-<!-- Un-comment the line for the applicable doc issue type to add its label.
-     Note that all text on that line is deleted upon issue creation. -->
-<!-- /label ~"docs:fix" - Correction or clarification needed. -->
-<!-- /label ~"docs:new" - New doc needed to cover a new topic or use case. -->
-<!-- /label ~"docs:improvement" - Improving an existing doc; e.g. adding a diagram, adding or rewording text, resolving redundancies, cross-linking, etc. -->
-<!-- /label ~"docs:revamp" - Review a page or group of pages in order to plan and implement major improvements/rewrites. -->
-<!-- /label ~"docs:other" - Anything else. -->
-
 ### Problem to solve
 
 <!-- Include the following detail as necessary:
@@ -50,4 +40,4 @@
 
 <!-- E.g. related GitLab issues/MRs -->
 
-/label ~Documentation
+/label ~documentation

.gitlab/merge_request_templates/Change documentation location.md

@@ -15,7 +15,7 @@ Closes
 ## Moving docs to a new location?
 
 Read the guidelines:
-https://docs.gitlab.com/ce/development/documentation/index.html#changing-document-location
+https://docs.gitlab.com/ee/development/documentation/index.html#changing-document-location
 
 - [ ] Make sure the old link is not removed and has its contents replaced with
       a link to the new location.
@@ -29,4 +29,4 @@ https://docs.gitlab.com/ce/development/documentation/index.html#changing-documen
       with the changes as well (https://docs.gitlab.com/ce/development/documentation/index.html#cherry-picking-from-ce-to-ee).
 - [ ] Ping one of the technical writers for review.
 
-/label ~Documentation
+/label ~documentation

.gitlab/merge_request_templates/Documentation.md

@@ -37,4 +37,4 @@ All reviewers can help ensure accuracy, clarity, completeness, and adherence to
 1. [ ] Ensure a release milestone is set and that you merge the equivalent EE MR before the CE MR if both exist.
 1. [ ] If there has not been a technical writer review, [create an issue for one using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review).
 
-/label ~Documentation
+/label ~documentation

app/views/admin/users/_head.html.haml

@@ -10,7 +10,7 @@
 
   .float-right
     - if impersonation_enabled? && @user != current_user && @user.can?(:log_in)
-      = link_to 'Impersonate', impersonate_admin_user_path(@user), method: :post, class: "btn btn-nr btn-grouped btn-info"
+      = link_to 'Impersonate', impersonate_admin_user_path(@user), method: :post, class: "btn btn-nr btn-grouped btn-info", data: { qa_selector: 'impersonate_user_link' }
     = link_to edit_admin_user_path(@user), class: "btn btn-nr btn-grouped" do
       %i.fa.fa-pencil-square-o
       Edit

app/views/admin/users/_user.html.haml

-.gl-responsive-table-row{ role: 'row' }
+.gl-responsive-table-row{ role: 'row', data: { qa_selector: 'user_row_content' } }
   .table-section.section-40
     .table-mobile-header{ role: 'rowheader' }
       = _('Name')

app/views/admin/users/_user_detail.html.haml

@@ -4,7 +4,7 @@
     .row-main-content
       .row-title.str-truncated-100
         = image_tag avatar_icon_for_user(user), class: 'avatar s16 d-xs-flex d-md-none mr-1 prepend-top-2', alt: _('Avatar for %{name}') % { name: sanitize_name(user.name) }
-        = link_to user.name, admin_user_path(user), class: 'text-plain js-user-link', data: { user_id: user.id }
+        = link_to user.name, admin_user_path(user), class: 'text-plain js-user-link', data: { user_id: user.id, qa_selector: 'username_link' }
 
       = render_if_exists 'admin/users/user_listing_note', user: user
 

app/views/admin/users/index.html.haml

@@ -44,7 +44,7 @@
       = hidden_field_tag "filter", h(params[:filter])
     .search-holder
       .search-field-holder
-        = search_field_tag :search_query, params[:search_query], placeholder: s_('AdminUsers|Search by name, email or username'), class: 'form-control search-text-input js-search-input', spellcheck: false
+        = search_field_tag :search_query, params[:search_query], placeholder: s_('AdminUsers|Search by name, email or username'), class: 'form-control search-text-input js-search-input', spellcheck: false, data: { qa_selector: 'user_search_field' }
         - if @sort.present?
           = hidden_field_tag :sort, @sort
         = icon("search", class: "search-icon")

app/views/layouts/header/_default.html.haml

@@ -73,7 +73,7 @@
                 = render 'layouts/header/current_user_dropdown'
           - if has_impersonation_link
             %li.nav-item.impersonation.ml-0
-              = link_to admin_impersonation_path, class: 'nav-link impersonation-btn', method: :delete, title: _('Stop impersonation'), aria: { label: _('Stop impersonation') }, data: { toggle: 'tooltip', placement: 'bottom', container: 'body' } do
+              = link_to admin_impersonation_path, class: 'nav-link impersonation-btn', method: :delete, title: _('Stop impersonation'), aria: { label: _('Stop impersonation') }, data: { toggle: 'tooltip', placement: 'bottom', container: 'body', qa_selector: 'stop_impersonation_link' } do
                 = icon('user-secret')
           - if header_link?(:sign_in)
             %li.nav-item

app/views/layouts/nav/sidebar/_admin.html.haml

@@ -6,7 +6,7 @@
           = sprite_icon('admin', size: 24)
         .sidebar-context-title
           = _('Admin Area')
-    %ul.sidebar-top-level-items
+    %ul.sidebar-top-level-items{ data: { qa_selector: 'admin_sidebar_overview_submenu_content' } }
       = nav_link(controller: %w(dashboard admin admin/projects users groups jobs runners gitaly_servers), html_options: {class: 'home'}) do
         = link_to admin_root_path, class: 'shortcuts-tree' do
           .nav-icon-container
@@ -28,7 +28,7 @@
               %span
                 = _('Projects')
           = nav_link(controller: :users) do
-            = link_to admin_users_path, title: _('Users') do
+            = link_to admin_users_path, title: _('Users') , data: { qa_selector: 'users_overview_link' } do
               %span
                 = _('Users')
           = nav_link(controller: :groups) do
@@ -49,13 +49,13 @@
                 = _('Gitaly Servers')
 
       = nav_link(controller: admin_monitoring_nav_links) do
-        = link_to admin_system_info_path do
+        = link_to admin_system_info_path, data: { qa_selector: 'admin_monitoring_link' } do
           .nav-icon-container
             = sprite_icon('monitor')
           %span.nav-item-name
             = _('Monitoring')
 
-        %ul.sidebar-sub-level-items
+        %ul.sidebar-sub-level-items{ data: { qa_selector: 'admin_sidebar_monitoring_submenu_content' } }
           = nav_link(controller: %w(system_info background_jobs logs health_check requests_profiles), html_options: { class: "fly-out-top-item" } ) do
             = link_to admin_system_info_path do
               %strong.fly-out-top-item-name
@@ -225,7 +225,7 @@
           %span.nav-item-name.qa-admin-settings-item
             = _('Settings')
 
-        %ul.sidebar-sub-level-items.qa-admin-sidebar-submenu
+        %ul.sidebar-sub-level-items.qa-admin-sidebar-settings-submenu
           = nav_link(controller: :application_settings, html_options: { class: "fly-out-top-item" } ) do
             = link_to admin_application_settings_path do
               %strong.fly-out-top-item-name

app/views/layouts/nav/sidebar/_profile.html.haml

@@ -64,7 +64,7 @@
               %strong.fly-out-top-item-name
                 = _('Access Tokens')
       = nav_link(controller: :emails) do
-        = link_to profile_emails_path do
+        = link_to profile_emails_path, data: { qa_selector: 'profile_emails_link' } do
           .nav-icon-container
             = sprite_icon('mail')
           %span.nav-item-name
@@ -76,7 +76,7 @@
                 = _('Emails')
       - if current_user.allow_password_authentication?
         = nav_link(controller: :passwords) do
-          = link_to edit_profile_password_path do
+          = link_to edit_profile_password_path , data: { qa_selector: 'profile_password_link' } do
             .nav-icon-container
               = sprite_icon('lock')
             %span.nav-item-name

app/views/profiles/emails/index.html.haml

@@ -13,9 +13,9 @@
     = form_for 'email', url: profile_emails_path do |f|
       .form-group
         = f.label :email, _('Email'), class: 'label-bold'
-        = f.text_field :email, class: 'form-control'
+        = f.text_field :email, class: 'form-control', data: { qa_selector: 'email_address_field' }
       .prepend-top-default
-        = f.submit _('Add email address'), class: 'btn btn-success'
+        = f.submit _('Add email address'), class: 'btn btn-success', data: { qa_selector: 'add_email_address_button' }
     %hr
     %h4.prepend-top-0
       = _('Linked emails (%{email_count})') % { email_count: @emails.count + 1 }
@@ -45,7 +45,7 @@
           - if @primary_email === current_user.notification_email
             %span.badge.badge-info= s_('Profiles|Default notification email')
       - @emails.each do |email|
-        %li
+        %li{ data: { qa_selector: 'email_row_content' } }
           = render partial: 'shared/email_with_badge', locals: { email: email.email, verified: email.confirmed? }
           %span.float-right
             - if email.email === current_user.commit_email
@@ -58,6 +58,6 @@
               - confirm_title = "#{email.confirmation_sent_at ? _('Resend confirmation email') : _('Send confirmation email')}"
               = link_to confirm_title, resend_confirmation_instructions_profile_email_path(email), method: :put, class: 'btn btn-sm btn-warning prepend-left-10'
 
-            = link_to profile_email_path(email), data: { confirm: _('Are you sure?')}, method: :delete, class: 'btn btn-sm btn-danger prepend-left-10' do
+            = link_to profile_email_path(email), data: { confirm: _('Are you sure?'), qa_selector: 'delete_email_link'}, method: :delete, class: 'btn btn-sm btn-danger prepend-left-10' do
               %span.sr-only= _('Remove')
               = icon('trash')

app/views/profiles/passwords/edit.html.haml

@@ -20,16 +20,16 @@
       - unless @user.password_automatically_set?
         .form-group
           = f.label :current_password, _('Current password'), class: 'label-bold'
-          = f.password_field :current_password, required: true, class: 'form-control'
+          = f.password_field :current_password, required: true, class: 'form-control', data: { qa_selector: 'current_password_field' }
           %p.form-text.text-muted
             = _('You must provide your current password in order to change it.')
       .form-group
         = f.label :password, _('New password'), class: 'label-bold'
-        = f.password_field :password, required: true, class: 'form-control'
+        = f.password_field :password, required: true, class: 'form-control', data: { qa_selector: 'new_password_field' }
       .form-group
         = f.label :password_confirmation, _('Password confirmation'), class: 'label-bold'
-        = f.password_field :password_confirmation, required: true, class: 'form-control'
+        = f.password_field :password_confirmation, required: true, class: 'form-control', data: { qa_selector: 'confirm_password_field' }
       .prepend-top-default.append-bottom-default
-        = f.submit _('Save password'), class: "btn btn-success append-right-10"
+        = f.submit _('Save password'), class: "btn btn-success append-right-10", data: { qa_selector: 'save_password_button' }
         - unless @user.password_automatically_set?
           = link_to _('I forgot my password'), reset_profile_password_path, method: :put, class: "account-btn-link"

danger/documentation/Dangerfile

@@ -20,8 +20,8 @@ unless docs_paths_to_review.empty?
       - [Documentation workflows](https://docs.gitlab.com/ee/development/documentation/workflow.html) for information on when to assign a merge request for review.
     MARKDOWN
 
-    unless gitlab.mr_labels.include?('Documentation')
-      warn 'This merge request is missing the ~Documentation label.'
+    unless gitlab.mr_labels.include?('documentation')
+      warn 'This merge request is missing the ~documentation label.'
     end
   end
 end

doc/administration/geo/disaster_recovery/index.md

@@ -51,7 +51,7 @@ must disable the **primary** node.
 
    NOTE: **Note:**
    (**CentOS only**) In CentOS 6 or older, there is no easy way to prevent GitLab from being
-   started if the machine reboots isn't available (see [gitlab-org/omnibus-gitlab#3058]).
+   started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3058)).
    It may be safest to uninstall the GitLab package completely:
 
    ```sh
@@ -317,6 +317,5 @@ section to resolve the error. Otherwise, the secret is lost and you'll need to
 [setup-geo]: ../replication/index.md#setup-instructions
 [updating-geo]: ../replication/version_specific_updates.md#updating-to-gitlab-105
 [sec-tfa]: ../../../security/two_factor_authentication.md#disabling-2fa-for-everyone
-[gitlab-org/omnibus-gitlab#3058]: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3058
 [initiate-the-replication-process]: ../replication/database.html#step-3-initiate-the-replication-process
 [configure-the-primary-server]: ../replication/database.html#step-1-configure-the-primary-server

doc/administration/geo/replication/configuration.md

@@ -25,7 +25,7 @@ Any change that requires access to the **Admin Area** needs to be done in the
 
 GitLab stores a number of secret values in the `/etc/gitlab/gitlab-secrets.json`
 file which *must* be the same on all nodes. Until there is
-a means of automatically replicating these between nodes (see issue [gitlab-org/gitlab#3789]),
+a means of automatically replicating these between nodes (see [issue #3789](https://gitlab.com/gitlab-org/gitlab/issues/3789)),
 they must be manually replicated to the **secondary** node.
 
 1. SSH into the **primary** node, and execute the command below:
@@ -75,7 +75,7 @@ they must be manually replicated to the **secondary** node.
 ### Step 2. Manually replicate the **primary** node's SSH host keys
 
 GitLab integrates with the system-installed SSH daemon, designating a user
-(typically named git) through which all access requests are handled.
+(typically named `git`) through which all access requests are handled.
 
 In a [Disaster Recovery] situation, GitLab system
 administrators will promote a **secondary** node to the **primary** node. DNS records for the
@@ -299,7 +299,6 @@ See the [troubleshooting document](troubleshooting.md).
 [setup-geo-omnibus]: index.md#using-omnibus-gitlab
 [Hashed Storage]: ../../repository_storage_types.md
 [Disaster Recovery]: ../disaster_recovery/index.md
-[gitlab-org/gitlab#3789]: https://gitlab.com/gitlab-org/gitlab/issues/3789
 [gitlab-com/infrastructure#2821]: https://gitlab.com/gitlab-com/infrastructure/issues/2821
 [omnibus-ssl]: https://docs.gitlab.com/omnibus/settings/ssl.html
 [using-geo]: using_a_geo_server.md

doc/administration/geo/replication/database.md

@@ -443,15 +443,15 @@ data before running `pg_basebackup`.
 
 The replication process is now complete.
 
-## PGBouncer support (optional)
+## PgBouncer support (optional)
 
-[PGBouncer](http://pgbouncer.github.io/) may be used with GitLab Geo to pool
-PostgreSQL connections. We recommend using PGBouncer if you use GitLab in a
+[PgBouncer](http://pgbouncer.github.io/) may be used with GitLab Geo to pool
+PostgreSQL connections. We recommend using PgBouncer if you use GitLab in a
 high-availability configuration with a cluster of nodes supporting a Geo
 **primary** node and another cluster of nodes supporting a Geo **secondary** node. For more
 information, see [High Availability with GitLab Omnibus](../../high_availability/database.md#high-availability-with-gitlab-omnibus-premium-only).
 
-For a Geo **secondary** node to work properly with PGBouncer in front of the database,
+For a Geo **secondary** node to work properly with PgBouncer in front of the database,
 it will need a separate read-only user to make [PostgreSQL FDW queries][FDW]
 work:
 

doc/administration/geo/replication/faq.md

@@ -43,9 +43,9 @@ attachments / avatars and the whole database. This means user accounts,
 issues, merge requests, groups, project data, etc., will be available for
 query.
 
-## Can I git push to a **secondary** node?
+## Can I `git push` to a **secondary** node?
 
-Yes!  Pushing directly to a **secondary** node (for both HTTP and SSH, including git-lfs) was [introduced](https://about.gitlab.com/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
+Yes!  Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
 
 ## How long does it take to have a commit replicated to a **secondary** node?
 

doc/administration/geo/replication/high_availability.md

@@ -8,7 +8,7 @@ described, it is possible to adapt these instructions to your needs.
 
 ![Geo HA Diagram](../../high_availability/img/geo-ha-diagram.png)
 
-_[diagram source - gitlab employees only][diagram-source]_
+_[diagram source - GitLab employees only][diagram-source]_
 
 The topology above assumes that the **primary** and **secondary** Geo clusters
 are located in two separate locations, on their own virtual network
@@ -274,15 +274,15 @@ After making these changes [Reconfigure GitLab][gitlab-reconfigure] so the chang
 
 On the secondary the following GitLab frontend services will be enabled:
 
-- geo-logcursor
-- gitlab-pages
-- gitlab-workhorse
-- logrotate
-- nginx
-- registry
-- remote-syslog
-- sidekiq
-- unicorn
+- `geo-logcursor`
+- `gitlab-pages`
+- `gitlab-workhorse`
+- `logrotate`
+- `nginx`
+- `registry`
+- `remote-syslog`
+- `sidekiq`
+- `unicorn`
 
 Verify these services by running `sudo gitlab-ctl status` on the frontend
 application servers.

doc/administration/geo/replication/index.md

@@ -63,7 +63,7 @@ Keep in mind that:
   - Get user data for logins (API).
   - Replicate repositories, LFS Objects, and Attachments (HTTPS + JWT).
 - Since GitLab Premium 10.0, the **primary** node no longer talks to **secondary** nodes to notify for changes (API).
-- Pushing directly to a **secondary** node (for both HTTP and SSH, including git-lfs) was [introduced](https://about.gitlab.com/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
+- Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
 - There are [limitations](#current-limitations) in the current implementation.
 
 ### Architecture
@@ -240,7 +240,7 @@ This list of limitations only reflects the latest version of GitLab. If you are
 
 - Pushing directly to a **secondary** node redirects (for HTTP) or proxies (for SSH) the request to the **primary** node instead of [handling it directly](https://gitlab.com/gitlab-org/gitlab/issues/1381), except when using Git over HTTP with credentials embedded within the URI. For example, `https://user:password@secondary.tld`.
 - The **primary** node has to be online for OAuth login to happen. Existing sessions and Git are not affected.
-- The installation takes multiple manual steps that together can take about an hour depending on circumstances. We are working on improving this experience. See [gitlab-org/omnibus-gitlab#2978](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2978) for details.
+- The installation takes multiple manual steps that together can take about an hour depending on circumstances. We are working on improving this experience. See [Omnibus GitLab issue #2978](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2978) for details.
 - Real-time updates of issues/merge requests (for example, via long polling) doesn't work on the **secondary** node.
 - [Selective synchronization](configuration.md#selective-synchronization) applies only to files and repositories. Other datasets are replicated to the **secondary** node in full, making it inappropriate for use as an access control mechanism.
 - Object pools for forked project deduplication work only on the **primary** node, and are duplicated on the **secondary** node.

doc/administration/geo/replication/security_review.md

@@ -49,9 +49,9 @@ questions from [owasp.org](https://www.owasp.org).
 ### How do the end‐users interact with the application?
 
 - **Secondary** nodes provide all the interfaces a **primary** node does
-  (notably a HTTP/HTTPS web application, and HTTP/HTTPS or SSH git repository
+  (notably a HTTP/HTTPS web application, and HTTP/HTTPS or SSH Git repository
   access), but is constrained to read-only activities. The principal use case is
-  envisioned to be cloning git repositories from the **secondary** node in favor of the
+  envisioned to be cloning Git repositories from the **secondary** node in favor of the
   **primary** node, but end-users may use the GitLab web interface to view projects,
   issues, merge requests, snippets, etc.
 
@@ -229,7 +229,7 @@ questions from [owasp.org](https://www.owasp.org).
 - A static secret shared across all hosts in a GitLab deployment.
 - In transit, data should be encrypted, although the application does permit
   communication to proceed unencrypted. The two main transits are the **secondary** node’s
-  replication process for PostgreSQL, and for git repositories/files. Both should
+  replication process for PostgreSQL, and for Git repositories/files. Both should
   be protected using TLS, with the keys for that managed via Omnibus per existing
   configuration for end-user access to GitLab.
 

doc/administration/geo/replication/troubleshooting.md

@@ -252,7 +252,7 @@ to start again from scratch, there are a few steps that can help you:
    gitlab-ctl stop geo-logcursor
    ```
 
-   You can watch sidekiq logs to know when sidekiq jobs processing have finished:
+   You can watch Sidekiq logs to know when Sidekiq jobs processing have finished:
 
    ```sh
    gitlab-ctl tail sidekiq
@@ -280,8 +280,8 @@ to start again from scratch, there are a few steps that can help you:
    Any uploaded content like file attachments, avatars or LFS objects are stored in a
    subfolder in one of the two paths below:
 
-   - /var/opt/gitlab/gitlab-rails/shared
-   - /var/opt/gitlab/gitlab-rails/uploads
+   - `/var/opt/gitlab/gitlab-rails/shared`
+   - `/var/opt/gitlab/gitlab-rails/uploads`
 
    To rename all of them:
 

doc/administration/geo/replication/using_a_geo_server.md

@@ -4,7 +4,7 @@
 
 After you set up the [database replication and configure the Geo nodes][req], use your closest GitLab node as you would a normal standalone GitLab instance.
 
-Pushing directly to a **secondary** node (for both HTTP, SSH including git-lfs) was [introduced](https://about.gitlab.com/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
+Pushing directly to a **secondary** node (for both HTTP, SSH including Git LFS) was [introduced](https://about.gitlab.com/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
 
 Example of the output you will see when pushing to a **secondary** node:
 

doc/administration/high_availability/README.md

@@ -42,7 +42,7 @@ complexity.
 - Sidekiq - Asynchronous/Background jobs
 - PostgreSQL - Database
   - Consul - Database service discovery and health checks/failover
-  - PGBouncer - Database pool manager
+  - PgBouncer - Database pool manager
 - Redis - Key/Value store (User sessions, cache, queue for Sidekiq)
   - Sentinel - Redis health check/failover manager
 - Gitaly - Provides high-level RPC access to Git repositories
@@ -138,7 +138,7 @@ the contention.
 - 3 PostgreSQL nodes
 - 2 Redis nodes
 - 3 Consul/Sentinel nodes
-- 2 or more GitLab application nodes (Unicorn, Workhorse, Sidekiq, PGBouncer)
+- 2 or more GitLab application nodes (Unicorn, Workhorse, Sidekiq, PgBouncer)
 - 1 NFS/Gitaly server
 - 1 Monitoring node (Prometheus, Grafana)
 
@@ -165,7 +165,7 @@ contention due to certain workloads.
 #### Reference Architecture
 
 - **Supported Users (approximate):** 10,000
-- **Known Issues:** While validating the reference architecture, slow endpoints were discovered and are being investigated. [gitlab-org/gitlab-foss/issues/64335](https://gitlab.com/gitlab-org/gitlab-foss/issues/64335)
+- **Known Issues:** While validating the reference architecture, slow endpoints were discovered and are being investigated. [See issue #64335](https://gitlab.com/gitlab-org/gitlab-foss/issues/64335)
 
 The Support and Quality teams built, performance tested, and validated an
 environment that supports about 10,000 users. The specifications below are a

doc/administration/high_availability/consul.md

@@ -6,7 +6,7 @@ type: reference
 
 As part of its High Availability stack, GitLab Premium includes a bundled version of [Consul](https://www.consul.io/) that can be managed through `/etc/gitlab/gitlab.rb`.
 
-A Consul cluster consists of multiple server agents, as well as client agents that run on other nodes which need to talk to the consul cluster.
+A Consul cluster consists of multiple server agents, as well as client agents that run on other nodes which need to talk to the Consul cluster.
 
 ## Prerequisites
 
@@ -96,7 +96,7 @@ Ideally all nodes will have a `Status` of `alive`.
 
 **Note**: This section only applies to server agents. It is safe to restart client agents whenever needed.
 
-If it is necessary to restart the server cluster, it is important to do this in a controlled fashion in order to maintain quorum. If quorum is lost, you will need to follow the consul [outage recovery](#outage-recovery) process to recover the cluster.
+If it is necessary to restart the server cluster, it is important to do this in a controlled fashion in order to maintain quorum. If quorum is lost, you will need to follow the Consul [outage recovery](#outage-recovery) process to recover the cluster.
 
 To be safe, we recommend you only restart one server agent at a time to ensure the cluster remains intact.
 
@@ -129,7 +129,7 @@ To fix this:
 
 1. Run `gitlab-ctl reconfigure`
 
-If you still see the errors, you may have to [erase the consul database and reinitialize](#recreate-from-scratch) on the affected node.
+If you still see the errors, you may have to [erase the Consul database and reinitialize](#recreate-from-scratch) on the affected node.
 
 ### Consul agents do not start - Multiple private IPs
 
@@ -162,7 +162,7 @@ If you lost enough server agents in the cluster to break quorum, then the cluste
 
 #### Recreate from scratch
 
-By default, GitLab does not store anything in the consul cluster that cannot be recreated. To erase the consul database and reinitialize
+By default, GitLab does not store anything in the Consul cluster that cannot be recreated. To erase the Consul database and reinitialize
 
 ```
 # gitlab-ctl stop consul
@@ -174,4 +174,4 @@ After this, the cluster should start back up, and the server agents rejoin. Shor
 
 #### Recover a failed cluster
 
-If you have taken advantage of consul to store other data, and want to restore the failed cluster, please follow the [Consul guide](https://www.consul.io/docs/guides/outage.html) to recover a failed cluster.
+If you have taken advantage of Consul to store other data, and want to restore the failed cluster, please follow the [Consul guide](https://www.consul.io/docs/guides/outage.html) to recover a failed cluster.

doc/administration/high_availability/database.md

@@ -153,9 +153,9 @@ Database nodes run two services with PostgreSQL:
   - Instructing remaining servers to follow the new master node.
 
   On failure, the old master node is automatically evicted from the cluster, and should be rejoined manually once recovered.
-- Consul. Monitors the status of each node in the database cluster and tracks its health in a service definition on the consul cluster.
+- Consul. Monitors the status of each node in the database cluster and tracks its health in a service definition on the Consul cluster.
 
-Alongside pgbouncer, there is a consul agent that watches the status of the PostgreSQL service. If that status changes, consul runs a script which updates the configuration and reloads pgbouncer
+Alongside PgBouncer, there is a Consul agent that watches the status of the PostgreSQL service. If that status changes, Consul runs a script which updates the configuration and reloads PgBouncer
 
 ##### Connection flow
 
@@ -198,7 +198,7 @@ When using default setup, minimum configuration requires:
 
 - `CONSUL_USERNAME`. Defaults to `gitlab-consul`
 - `CONSUL_DATABASE_PASSWORD`. Password for the database user.
-- `CONSUL_PASSWORD_HASH`. This is a hash generated out of consul username/password pair.
+- `CONSUL_PASSWORD_HASH`. This is a hash generated out of Consul username/password pair.
    Can be generated with:
 
    ```sh
@@ -248,26 +248,26 @@ We will need the following password information for the application's database u
   sudo gitlab-ctl pg-password-md5 POSTGRESQL_USERNAME
   ```
 
-##### Pgbouncer information
+##### PgBouncer information
 
 When using default setup, minimum configuration requires:
 
 - `PGBOUNCER_USERNAME`. Defaults to `pgbouncer`
-- `PGBOUNCER_PASSWORD`. This is a password for pgbouncer service.
-- `PGBOUNCER_PASSWORD_HASH`. This is a hash generated out of pgbouncer username/password pair.
+- `PGBOUNCER_PASSWORD`. This is a password for PgBouncer service.
+- `PGBOUNCER_PASSWORD_HASH`. This is a hash generated out of PgBouncer username/password pair.
   Can be generated with:
 
   ```sh
   sudo gitlab-ctl pg-password-md5 PGBOUNCER_USERNAME
   ```
 
-- `PGBOUNCER_NODE`, is the IP address or a FQDN of the node running Pgbouncer.
+- `PGBOUNCER_NODE`, is the IP address or a FQDN of the node running PgBouncer.
 
 Few notes on the service itself:
 
 - The service runs as the same system account as the database
   - In the package, this is by default `gitlab-psql`
-- If you use a non-default user account for Pgbouncer service (by default `pgbouncer`), you will have to specify this username. We will refer to this requirement with `PGBOUNCER_USERNAME`.
+- If you use a non-default user account for PgBouncer service (by default `pgbouncer`), you will have to specify this username. We will refer to this requirement with `PGBOUNCER_USERNAME`.
 - The service will have a regular database user account generated for it
   - This defaults to `repmgr`
 - Passwords will be stored in the following locations:
@@ -315,7 +315,7 @@ When installing the GitLab package, do not supply `EXTERNAL_URL` value.
    # Disable automatic database migrations
    gitlab_rails['auto_migrate'] = false
 
-   # Configure the consul agent
+   # Configure the Consul agent
    consul['services'] = %w(postgresql)
 
    # START user configuration
@@ -348,7 +348,7 @@ When installing the GitLab package, do not supply `EXTERNAL_URL` value.
 
 1. On secondary nodes, add all the configuration specified above for primary node
    to `/etc/gitlab/gitlab.rb`. In addition, append the following configuration
-   to inform gitlab-ctl that they are standby nodes initially and it need not
+   to inform `gitlab-ctl` that they are standby nodes initially and it need not
    attempt to register them as primary node
 
    ```
@@ -363,7 +363,7 @@ When installing the GitLab package, do not supply `EXTERNAL_URL` value.
 >
 > - If you want your database to listen on a specific interface, change the config:
 >   `postgresql['listen_address'] = '0.0.0.0'`.
-> - If your Pgbouncer service runs under a different user account,
+> - If your PgBouncer service runs under a different user account,
 >   you also need to specify: `postgresql['pgbouncer_user'] = PGBOUNCER_USERNAME` in
 >   your configuration.
 
@@ -484,9 +484,9 @@ or secondary. The most important thing here is that this command does not produc
 If there are errors it's most likely due to incorrect `gitlab-consul` database user permissions.
 Check the [Troubleshooting section](#troubleshooting) before proceeding.
 
-#### Configuring the Pgbouncer node
+#### Configuring the PgBouncer node
 
-See our [documentation for Pgbouncer](pgbouncer.md) for information on running Pgbouncer as part of an HA setup.
+See our [documentation for PgBouncer](pgbouncer.md) for information on running PgBouncer as part of an HA setup.
 
 #### Configuring the Application nodes
 
@@ -515,10 +515,10 @@ Ensure that all migrations ran:
 gitlab-rake gitlab:db:configure
 ```
 
-> **Note**: If you encounter a `rake aborted!` error stating that PGBouncer is failing to connect to
-PostgreSQL it may be that your PGBouncer node's IP address is missing from
+> **Note**: If you encounter a `rake aborted!` error stating that PgBouncer is failing to connect to
+PostgreSQL it may be that your PgBouncer node's IP address is missing from
 PostgreSQL's `trust_auth_cidr_addresses` in `gitlab.rb` on your database nodes. See
-[PGBouncer error `ERROR:  pgbouncer cannot connect to server`](#pgbouncer-error-error-pgbouncer-cannot-connect-to-server)
+[PgBouncer error `ERROR:  pgbouncer cannot connect to server`](#pgbouncer-error-error-pgbouncer-cannot-connect-to-server)
 in the Troubleshooting section before proceeding.
 
 ##### Ensure GitLab is running
@@ -533,7 +533,7 @@ Here we'll show you some fully expanded example configurations.
 
 ##### Example recommended setup
 
-This example uses 3 consul servers, 3 postgresql servers, and 1 application node.
+This example uses 3 Consul servers, 3 PostgreSQL servers, and 1 application node.
 
 We start with all servers on the same 10.6.0.0/16 private network range, they
 can connect to each freely other on those addresses.
@@ -589,7 +589,7 @@ postgresql['shared_preload_libraries'] = 'repmgr_funcs'
 # Disable automatic database migrations
 gitlab_rails['auto_migrate'] = false
 
-# Configure the consul agent
+# Configure the Consul agent
 consul['services'] = %w(postgresql)
 
 postgresql['pgbouncer_user_password'] = '771a8625958a529132abe6f1a4acb19c'
@@ -635,7 +635,7 @@ postgresql['enable'] = false
 pgbouncer['enable'] = true
 consul['enable'] = true
 
-# Configure Pgbouncer
+# Configure PgBouncer
 pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
 
 # Configure Consul agent
@@ -691,7 +691,7 @@ After deploying the configuration follow these steps:
 
 1. On `10.6.0.31`, our application server
 
-   Set gitlab-consul's pgbouncer password to `toomanysecrets`
+   Set `gitlab-consul` user's PgBouncer password to `toomanysecrets`
 
    ```sh
    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
@@ -705,10 +705,10 @@ After deploying the configuration follow these steps:
 
 #### Example minimal setup
 
-This example uses 3 postgresql servers, and 1 application node.
+This example uses 3 PostgreSQL servers, and 1 application node.
 
-It differs from the [recommended setup](#example-recommended-setup) by moving the consul servers into the same servers we use for PostgreSQL.
-The trade-off is between reducing server counts, against the increased operational complexity of needing to deal with postgres [failover](#failover-procedure) and [restore](#restore-procedure) procedures in addition to [consul outage recovery](consul.md#outage-recovery) on the same set of machines.
+It differs from the [recommended setup](#example-recommended-setup) by moving the Consul servers into the same servers we use for PostgreSQL.
+The trade-off is between reducing server counts, against the increased operational complexity of needing to deal with postgres [failover](#failover-procedure) and [restore](#restore-procedure) procedures in addition to [Consul outage recovery](consul.md#outage-recovery) on the same set of machines.
 
 In this example we start with all servers on the same 10.6.0.0/16 private network range, they can connect to each freely other on those addresses.
 
@@ -744,7 +744,7 @@ postgresql['shared_preload_libraries'] = 'repmgr_funcs'
 # Disable automatic database migrations
 gitlab_rails['auto_migrate'] = false
 
-# Configure the consul agent
+# Configure the Consul agent
 consul['services'] = %w(postgresql)
 
 postgresql['pgbouncer_user_password'] = '771a8625958a529132abe6f1a4acb19c'
@@ -788,7 +788,7 @@ postgresql['enable'] = false
 pgbouncer['enable'] = true
 consul['enable'] = true
 
-# Configure Pgbouncer
+# Configure PgBouncer
 pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
 
 # Configure Consul agent
@@ -817,7 +817,7 @@ The manual steps for this configuration are the same as for the [example recomme
 #### Failover procedure
 
 By default, if the master database fails, `repmgrd` should promote one of the
-standby nodes to master automatically, and consul will update pgbouncer with
+standby nodes to master automatically, and Consul will update PgBouncer with
 the new master.
 
 If you need to failover manually, you have two options:
@@ -907,7 +907,7 @@ can require md5 authentication.
 
 ##### Trust specific addresses
 
-If you know the IP address, or FQDN of all database and pgbouncer nodes in the
+If you know the IP address, or FQDN of all database and PgBouncer nodes in the
 cluster, you can trust only those nodes.
 
 In `/etc/gitlab/gitlab.rb` on all of the database nodes, set
@@ -950,7 +950,7 @@ the previous section:
       1. Set `postgresql['md5_auth_cidr_addresses']` to the desired value
       1. Set `postgresql['sql_replication_user'] = 'gitlab_repmgr'`
       1. Reconfigure with `gitlab-ctl reconfigure`
-      1. Restart postgresql with `gitlab-ctl restart postgresql`
+      1. Restart PostgreSQL with `gitlab-ctl restart postgresql`
 
    1. Create a `.pgpass` file. Enter the `gitlab_repmgr` password twice to
       when asked:
@@ -959,7 +959,7 @@ the previous section:
       gitlab-ctl write-pgpass --user gitlab_repmgr --hostuser gitlab-psql --database '*'
       ```
 
-1. On each pgbouncer node, edit `/etc/gitlab/gitlab.rb`:
+1. On each PgBouncer node, edit `/etc/gitlab/gitlab.rb`:
    1. Ensure `gitlab_rails['db_password']` is set to the plaintext password for
       the `gitlab` database user
    1. [Reconfigure GitLab] for the changes to take effect
@@ -993,7 +993,7 @@ To restart either service, run `gitlab-ctl restart SERVICE`
 
 For PostgreSQL, it is usually safe to restart the master node by default. Automatic failover defaults to a 1 minute timeout. Provided the database returns before then, nothing else needs to be done. To be safe, you can stop `repmgrd` on the standby nodes first with `gitlab-ctl stop repmgrd`, then start afterwards with `gitlab-ctl start repmgrd`.
 
-On the consul server nodes, it is important to restart the consul service in a controlled fashion. Read our [consul documentation](consul.md#restarting-the-server-cluster) for instructions on how to restart the service.
+On the Consul server nodes, it is important to restart the Consul service in a controlled fashion. Read our [Consul documentation](consul.md#restarting-the-server-cluster) for instructions on how to restart the service.
 
 ### `gitlab-ctl repmgr-check-master` command produces errors
 
@@ -1010,16 +1010,16 @@ steps to fix the problem:
 
 Now there should not be errors. If errors still occur then there is another problem.
 
-### PGBouncer error `ERROR: pgbouncer cannot connect to server`
+### PgBouncer error `ERROR: pgbouncer cannot connect to server`
 
 You may get this error when running `gitlab-rake gitlab:db:configure` or you
-may see the error in the PGBouncer log file.
+may see the error in the PgBouncer log file.
 
 ```
 PG::ConnectionBad: ERROR:  pgbouncer cannot connect to server
 ```
 
-The problem may be that your PGBouncer node's IP address is not included in the
+The problem may be that your PgBouncer node's IP address is not included in the
 `trust_auth_cidr_addresses` setting in `/etc/gitlab/gitlab.rb` on the database nodes.
 
 You can confirm that this is the issue by checking the PostgreSQL log on the master

doc/administration/high_availability/gitlab.md

@@ -90,8 +90,8 @@ these additional steps before proceeding with GitLab installation.
 
    NOTE: **Note:** When you specify `https` in the `external_url`, as in the example
    above, GitLab assumes you have SSL certificates in `/etc/gitlab/ssl/`. If
-   certificates are not present, Nginx will fail to start. See
-   [Nginx documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
+   certificates are not present, NGINX will fail to start. See
+   [NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
    for more information.
 
    NOTE: **Note:** It is best to set the `uid` and `gid`s prior to the initial reconfigure
@@ -175,7 +175,7 @@ If you enable Monitoring, it must be enabled on **all** GitLab servers.
 
    CAUTION: **Warning:**
    After changing `unicorn['listen']` in `gitlab.rb`, and running `sudo gitlab-ctl reconfigure`,
-   it can take an extended period of time for unicorn to complete reloading after receiving a `HUP`.
+   it can take an extended period of time for Unicorn to complete reloading after receiving a `HUP`.
    For more information, see the [issue](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4401).
 
 ## Troubleshooting

doc/administration/high_availability/load_balancer.md

@@ -27,10 +27,10 @@ options:
 
 Configure your load balancer(s) to pass connections on port 443 as 'TCP' rather
 than 'HTTP(S)' protocol. This will pass the connection to the application nodes
-Nginx service untouched. Nginx will have the SSL certificate and listen on port 443.
+NGINX service untouched. NGINX will have the SSL certificate and listen on port 443.
 
-See [Nginx HTTPS documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
-for details on managing SSL certificates and configuring Nginx.
+See [NGINX HTTPS documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
+for details on managing SSL certificates and configuring NGINX.
 
 ### Load Balancer(s) terminate SSL without backend SSL
 
@@ -40,7 +40,7 @@ terminating SSL.
 
 Since communication between the load balancer(s) and GitLab will not be secure,
 there is some additional configuration needed. See
-[Nginx Proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#supporting-proxied-ssl)
+[NGINX Proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#supporting-proxied-ssl)
 for details.
 
 ### Load Balancer(s) terminate SSL with backend SSL
@@ -49,12 +49,12 @@ Configure your load balancer(s) to use the 'HTTP(S)' protocol rather than 'TCP'.
 The load balancer(s) will be responsible for managing SSL certificates that
 end users will see.
 
-Traffic will also be secure between the load balancer(s) and Nginx in this
+Traffic will also be secure between the load balancer(s) and NGINX in this
 scenario. There is no need to add configuration for proxied SSL since the
 connection will be secure all the way. However, configuration will need to be
 added to GitLab to configure SSL certificates. See
-[Nginx HTTPS documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
-for details on managing SSL certificates and configuring Nginx.
+[NGINX HTTPS documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
+for details on managing SSL certificates and configuring NGINX.
 
 ## Ports
 

doc/administration/high_availability/nfs.md

@@ -109,7 +109,7 @@ For more details on another person's experience with EFS, see
 ## Avoid using CephFS and GlusterFS
 
 GitLab strongly recommends against using CephFS and GlusterFS.
-These distributed file systems are not well-suited for GitLab's input/output access patterns because git uses many small files and access times and file locking times to propagate will make git activity very slow.
+These distributed file systems are not well-suited for GitLab's input/output access patterns because Git uses many small files and access times and file locking times to propagate will make Git activity very slow.
 
 ## Avoid using PostgreSQL with NFS
 
@@ -147,7 +147,7 @@ Note there are several options that you should consider using:
 
 ## A single NFS mount
 
-It's recommended to nest all gitlab data dirs within a mount, that allows automatic
+It's recommended to nest all GitLab data dirs within a mount, that allows automatic
 restore of backups without manually moving existing data.
 
 ```

doc/administration/high_availability/nfs_host_client_setup.md

@@ -56,7 +56,7 @@ You may need to update your server's firewall. See the [firewall section](#nfs-i
 
 ## Client/ GitLab application node Setup
 
-> Follow the instructions below to connect any GitLab rails application node running
+> Follow the instructions below to connect any GitLab Rails application node running
 inside your HA environment to the NFS server configured above.
 
 ### Step 1 - Install NFS Common on Client
@@ -108,7 +108,7 @@ When using the default Omnibus configuration you will need to share 5 data locat
 between all GitLab cluster nodes. No other locations should be shared. Changing the
 default file locations in `gitlab.rb` on the client allows you to have one main mount
 point and have all the required locations as subdirectories to use the NFS mount for
-git-data.
+`git-data`.
 
 ```text
 git_data_dirs({"default" => {"path" => "/nfs/home/var/opt/gitlab-data/git-data"}})

doc/administration/high_availability/pgbouncer.md

@@ -2,29 +2,29 @@
 type: reference
 ---
 
-# Working with the bundle Pgbouncer service
+# Working with the bundle PgBouncer service
 
-As part of its High Availability stack, GitLab Premium includes a bundled version of [Pgbouncer](https://pgbouncer.github.io/) that can be managed through `/etc/gitlab/gitlab.rb`.
+As part of its High Availability stack, GitLab Premium includes a bundled version of [PgBouncer](https://pgbouncer.github.io/) that can be managed through `/etc/gitlab/gitlab.rb`.
 
-In a High Availability setup, Pgbouncer is used to seamlessly migrate database connections between servers in a failover scenario.
+In a High Availability setup, PgBouncer is used to seamlessly migrate database connections between servers in a failover scenario.
 
 Additionally, it can be used in a non-HA setup to pool connections, speeding up response time while reducing resource usage.
 
-It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on its own dedicated node in a cluster.
+It is recommended to run PgBouncer alongside the `gitlab-rails` service, or on its own dedicated node in a cluster.
 
 ## Operations
 
-### Running Pgbouncer as part of an HA GitLab installation
+### Running PgBouncer as part of an HA GitLab installation
 
 1. Make sure you collect [`CONSUL_SERVER_NODES`](database.md#consul-information), [`CONSUL_PASSWORD_HASH`](database.md#consul-information), and [`PGBOUNCER_PASSWORD_HASH`](database.md#pgbouncer-information) before executing the next step.
 
 1. Edit `/etc/gitlab/gitlab.rb` replacing values noted in the `# START user configuration` section:
 
    ```ruby
-   # Disable all components except Pgbouncer and Consul agent
+   # Disable all components except PgBouncer and Consul agent
    roles ['pgbouncer_role']
 
-   # Configure Pgbouncer
+   # Configure PgBouncer
    pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
 
    # Configure Consul agent
@@ -59,13 +59,13 @@ It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on i
 1. Run `gitlab-ctl reconfigure`
 
 1. Create a `.pgpass` file so Consul is able to
-   reload pgbouncer. Enter the `PGBOUNCER_PASSWORD` twice when asked:
+   reload PgBouncer. Enter the `PGBOUNCER_PASSWORD` twice when asked:
 
    ```sh
    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
    ```
 
-#### PGBouncer Checkpoint
+#### PgBouncer Checkpoint
 
 1. Ensure the node is talking to the current master:
 
@@ -100,7 +100,7 @@ It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on i
    (2 rows)
    ```
 
-### Running Pgbouncer as part of a non-HA GitLab installation
+### Running PgBouncer as part of a non-HA GitLab installation
 
 1. Generate PGBOUNCER_USER_PASSWORD_HASH with the command `gitlab-ctl pg-password-md5 pgbouncer`
 
@@ -119,7 +119,7 @@ It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on i
 
    **Note:** If the database was already running, it will need to be restarted after reconfigure by running `gitlab-ctl restart postgresql`.
 
-1. On the node you are running pgbouncer on, make sure the following is set in `/etc/gitlab/gitlab.rb`
+1. On the node you are running PgBouncer on, make sure the following is set in `/etc/gitlab/gitlab.rb`
 
    ```ruby
    pgbouncer['enable'] = true
@@ -134,7 +134,7 @@ It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on i
 
 1. Run `gitlab-ctl reconfigure`
 
-1. On the node running unicorn, make sure the following is set in `/etc/gitlab/gitlab.rb`
+1. On the node running Unicorn, make sure the following is set in `/etc/gitlab/gitlab.rb`
 
    ```ruby
    gitlab_rails['db_host'] = 'PGBOUNCER_HOST'
@@ -144,13 +144,13 @@ It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on i
 
 1. Run `gitlab-ctl reconfigure`
 
-1. At this point, your instance should connect to the database through pgbouncer. If you are having issues, see the [Troubleshooting](#troubleshooting) section
+1. At this point, your instance should connect to the database through PgBouncer. If you are having issues, see the [Troubleshooting](#troubleshooting) section
 
 ## Enable Monitoring
 
 > [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3786) in GitLab 12.0.
 
-If you enable Monitoring, it must be enabled on **all** pgbouncer servers.
+If you enable Monitoring, it must be enabled on **all** PgBouncer servers.
 
 1. Create/edit `/etc/gitlab/gitlab.rb` and add the following configuration:
 
@@ -173,11 +173,11 @@ If you enable Monitoring, it must be enabled on **all** pgbouncer servers.
 
 1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
 
-### Interacting with pgbouncer
+### Interacting with PgBouncer
 
 #### Administrative console
 
-As part of omnibus-gitlab, we provide a command `gitlab-ctl pgb-console` to automatically connect to the pgbouncer administrative console. Please see the [pgbouncer documentation](https://pgbouncer.github.io/usage.html#admin-console) for detailed instructions on how to interact with the console.
+As part of Omnibus GitLab, we provide a command `gitlab-ctl pgb-console` to automatically connect to the PgBouncer administrative console. Please see the [PgBouncer documentation](https://pgbouncer.github.io/usage.html#admin-console) for detailed instructions on how to interact with the console.
 
 To start a session, run
 
@@ -235,7 +235,7 @@ ote_pid | tls
 
 ## Troubleshooting
 
-In case you are experiencing any issues connecting through pgbouncer, the first place to check is always the logs:
+In case you are experiencing any issues connecting through PgBouncer, the first place to check is always the logs:
 
 ```shell
 # gitlab-ctl tail pgbouncer

doc/administration/high_availability/redis.md

@@ -397,7 +397,7 @@ The prerequisites for a HA Redis setup are the following:
 
 1. [Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect.
 
-> Note: You can specify multiple roles like sentinel and redis as:
+> Note: You can specify multiple roles like sentinel and Redis as:
 > `roles ['redis_sentinel_role', 'redis_master_role']`. Read more about high
 > availability roles at <https://docs.gitlab.com/omnibus/roles/>.
 
@@ -446,7 +446,7 @@ The prerequisites for a HA Redis setup are the following:
 1. [Reconfigure Omnibus GitLab][reconfigure] for the changes to take effect.
 1. Go through the steps again for all the other slave nodes.
 
-> Note: You can specify multiple roles like sentinel and redis as:
+> Note: You can specify multiple roles like sentinel and Redis as:
 > `roles ['redis_sentinel_role', 'redis_slave_role']`. Read more about high
 > availability roles at <https://docs.gitlab.com/omnibus/roles/>.
 
@@ -628,7 +628,7 @@ single-machine install, to rotate the **Master** to one of the new nodes.
 
 Make the required changes in configuration and restart the new nodes again.
 
-To disable redis in the single install, edit `/etc/gitlab/gitlab.rb`:
+To disable Redis in the single install, edit `/etc/gitlab/gitlab.rb`:
 
 ```ruby
 redis['enable'] = false
@@ -902,7 +902,7 @@ You can check if everything is correct by connecting to each server using
 /opt/gitlab/embedded/bin/redis-cli -h <redis-host-or-ip> -a '<redis-password>' info replication
 ```
 
-When connected to a `master` redis, you will see the number of connected
+When connected to a `master` Redis, you will see the number of connected
 `slaves`, and a list of each with connection details:
 
 ```
@@ -948,7 +948,7 @@ to [this issue][gh-531].
 You must make sure you are defining the same value in `redis['master_name']`
 and `redis['master_pasword']` as you defined for your sentinel node.
 
-The way the redis connector `redis-rb` works with sentinel is a bit
+The way the Redis connector `redis-rb` works with sentinel is a bit
 non-intuitive. We try to hide the complexity in omnibus, but it still requires
 a few extra configs.
 

doc/administration/high_availability/redis_source.md

@@ -341,7 +341,7 @@ to [this upstream issue][gh-531].
 You must make sure that `resque.yml` and `sentinel.conf` are configured correctly,
 otherwise `redis-rb` will not work properly.
 
-The `master-group-name` ('gitlab-redis') defined in (`sentinel.conf`)
+The `master-group-name` (`gitlab-redis`) defined in (`sentinel.conf`)
 **must** be used as the hostname in GitLab (`resque.yml`):
 
 ```conf

doc/api/settings.md

----
-table_display_block: true
----
-
 # Application settings API
 
 These API calls allow you to read and modify GitLab instance

doc/ci/variables/README.md

 ---
-table_display_block: true
 type: reference
 ---
 

doc/development/architecture.md

----
-table_display_block: true
----
-
 # GitLab Architecture Overview
 
 ## Software delivery

doc/development/contributing/issue_workflow.md

@@ -45,8 +45,8 @@ Most issues will have labels for at least one of the following:
 - Category: ~"Category:Code Analytics", ~"Category:DevOps Score", ~"Category:Templates", etc.
 - Feature: ~wiki, ~ldap, ~api, ~issues, ~"merge requests", etc.
 - Department: ~UX, ~Quality
-- Team: ~Documentation, ~Delivery
-- Specialization: ~frontend, ~backend
+- Team: ~"Technical Writing", ~Delivery
+- Specialization: ~frontend, ~backend, ~documentation
 - Release Scoping: ~Deliverable, ~Stretch, ~"Next Patch Release"
 - Priority: ~P1, ~P2, ~P3, ~P4
 - Severity: ~S1, ~S2, ~S3, ~S4
@@ -228,7 +228,7 @@ people.
 The current team labels are:
 
 - ~Delivery
-- ~Documentation
+- ~"Technical Writing"
 
 #### Naming and color convention
 
@@ -241,6 +241,7 @@ These labels narrow the [specialization](https://about.gitlab.com/company/team/s
 
 - ~frontend
 - ~backend
+- ~documentation
 
 ### Release scoping labels
 

doc/development/documentation/feature-change-workflow.md

@@ -77,7 +77,7 @@ and default merge request template will assist you with following this process.
 For issues requiring any new or updated documentation, the Product Manager (PM)
 must:
 
-- Add the `Documentation` label.
+- Add the ~documentation label.
 - Confirm or add the [documentation requirements](#documentation-requirements-in-feature-issues).
 - Ensure the issue contains any new or updated feature name, overview/description,
   and use cases, as required per the [documentation structure and template](structure.md), when applicable.
@@ -92,7 +92,7 @@ do the following:
 
 #### Authoring
 
-As a developer, if a ~feature issue also contains the ~Documentation label, you must ship the new or updated documentation with the code of the feature. The documentation is an essential part of the product.
+As a developer, if a ~feature issue also contains the ~documentation label, you must ship the new or updated documentation with the code of the feature. The documentation is an essential part of the product.
 Technical writers are happy to help, as requested and planned on an issue-by-issue basis.
 
 For feature issues requiring documentation, follow the process below unless otherwise agreed with the product manager and technical writer for a given issue:

doc/development/documentation/styleguide.md

@@ -239,20 +239,6 @@ Do not include the same information in multiple places. [Link to a SSOT instead.
   - List item 2
   ```
 
-### Tables overlapping the TOC
-
-By default, all tables have a width of 100% on docs.gitlab.com.
-In a few cases, the table will overlap the table of contents (ToC).
-For these cases, add an entry to the document's frontmatter to
-render them displaying block. This will make sure the table
-is displayed behind the ToC, scrolling horizontally:
-
-```md
----
-table_display_block: true
----
-```
-
 ### Emphasis
 
 - Use double asterisks (`**`) to mark a word or text in bold (`**bold**`).

doc/user/admin_area/geo_nodes.md

@@ -16,7 +16,7 @@ All Geo nodes have the following settings:
 | Setting | Description |
 | --------| ----------- |
 | Primary | This marks a Geo Node as **primary** node. There can be only one **primary** node; make sure that you first add the **primary** node and then all the others. |
-| Name    | The unique identifier for the Geo node. Must match the setting `gitlab_rails[geo_node_name]` in `/etc/gitlab/gitlab.rb`. The setting defaults to `external_url` with a trailing slash. |
+| Name    | The unique identifier for the Geo node. Must match the setting `gitlab_rails['geo_node_name']` in `/etc/gitlab/gitlab.rb`. The setting defaults to `external_url` with a trailing slash. |
 | URL     | The instance's user-facing URL. |
 
 The node you're reading from is indicated with a green `Current node` label, and
@@ -71,7 +71,7 @@ terminated at the load balancer.
 
 In GitLab 11.11, **secondary** nodes can use identical external URLs as long as
 a unique `name` is set for each Geo node. The `gitlab.rb` setting
-`gitlab_rails[geo_node_name]` must:
+`gitlab_rails['geo_node_name']` must:
 
 - Be set for each GitLab instance that runs `unicorn`, `sidekiq`, or `geo_logcursor`.
 - Match a Geo node name.

doc/user/application_security/sast/analyzers.md

----
-table_display_block: true
----
-
 # SAST Analyzers **(ULTIMATE)**
 
 SAST relies on underlying third party tools that are wrapped into what we call

doc/user/gitlab_com/index.md

@@ -180,13 +180,17 @@ and the following environment variables:
 | Setting                                    | GitLab.com | Default   |
 |--------                                    |----------- |--------   |
 | `SIDEKIQ_DAEMON_MEMORY_KILLER`             | -          | -         |
-| `SIDEKIQ_MEMORY_KILLER_MAX_RSS`            | `16000000` | `2000000` |
+| `SIDEKIQ_MEMORY_KILLER_MAX_RSS`            | `2000000`  | `2000000` |
 | `SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS`     | -          | -         |
 | `SIDEKIQ_MEMORY_KILLER_CHECK_INTERVAL`     | -          | `3`       |
 | `SIDEKIQ_MEMORY_KILLER_GRACE_TIME`         | -          | `900`     |
 | `SIDEKIQ_MEMORY_KILLER_SHUTDOWN_WAIT`      | -          | `30`      |
 | `SIDEKIQ_LOG_ARGUMENTS`                    | `1`        | -         |
 
+NOTE: **Note:**
+The `SIDEKIQ_MEMORY_KILLER_MAX_RSS` setting is `16000000` on Sidekiq import
+nodes and Sidekiq export nodes.
+
 ## Cron jobs
 
 Periodically executed jobs by Sidekiq, to self-heal GitLab, do external

lib/gitlab/danger/helper.rb

@@ -89,7 +89,7 @@ module Gitlab
       end
 
       CATEGORY_LABELS = {
-        docs: "~Documentation", # Docs are reviewed along DevOps stages, so don't need roulette for now.
+        docs: "~documentation", # Docs are reviewed along DevOps stages, so don't need roulette for now.
         none: "",
         qa: "~QA",
         test: "~test for `spec/features/*`",

qa/qa.rb

@@ -290,6 +290,8 @@ module QA
       autoload :Menu, 'qa/page/profile/menu'
       autoload :PersonalAccessTokens, 'qa/page/profile/personal_access_tokens'
       autoload :SSHKeys, 'qa/page/profile/ssh_keys'
+      autoload :Emails, 'qa/page/profile/emails'
+      autoload :Password, 'qa/page/profile/password'
       autoload :TwoFactorAuth, 'qa/page/profile/two_factor_auth'
     end
 
@@ -332,6 +334,13 @@ module QA
           autoload :PerformanceBar, 'qa/page/admin/settings/component/performance_bar'
         end
       end
+
+      module Overview
+        module Users
+          autoload :Index, 'qa/page/admin/overview/users/index'
+          autoload :Show, 'qa/page/admin/overview/users/show'
+        end
+      end
     end
 
     module Mattermost

qa/qa/page/admin/menu.rb

@@ -6,12 +6,16 @@ module QA
       class Menu < Page::Base
         view 'app/views/layouts/nav/sidebar/_admin.html.haml' do
           element :admin_sidebar
-          element :admin_sidebar_submenu
+          element :admin_sidebar_settings_submenu
           element :admin_settings_item
           element :admin_settings_repository_item
           element :admin_settings_general_item
           element :admin_settings_metrics_and_profiling_item
           element :admin_settings_preferences_link
+          element :admin_monitoring_link
+          element :admin_sidebar_monitoring_submenu_content
+          element :admin_sidebar_overview_submenu_content
+          element :users_overview_link
         end
 
         view 'app/views/layouts/nav/sidebar/_admin.html.haml' do
@@ -19,59 +23,65 @@ module QA
         end
 
         def go_to_preferences_settings
-          hover_settings do
-            within_submenu do
+          hover_element(:admin_settings_item) do
+            within_submenu(:admin_sidebar_settings_submenu) do
               click_element :admin_settings_preferences_link
             end
           end
         end
 
         def go_to_repository_settings
-          hover_settings do
-            within_submenu do
+          hover_element(:admin_settings_item) do
+            within_submenu(:admin_sidebar_settings_submenu) do
               click_element :admin_settings_repository_item
             end
           end
         end
 
         def go_to_integration_settings
-          hover_settings do
-            within_submenu do
+          hover_element(:admin_settings_item) do
+            within_submenu(:admin_sidebar_settings_submenu) do
               click_element :integration_settings_link
             end
           end
         end
 
         def go_to_general_settings
-          hover_settings do
-            within_submenu do
+          hover_element(:admin_settings_item) do
+            within_submenu(:admin_sidebar_settings_submenu) do
               click_element :admin_settings_general_item
             end
           end
         end
 
         def go_to_metrics_and_profiling_settings
-          hover_settings do
-            within_submenu do
+          hover_element(:admin_settings_item) do
+            within_submenu(:admin_sidebar_settings_submenu) do
               click_element :admin_settings_metrics_and_profiling_item
             end
           end
         end
 
         def go_to_network_settings
-          hover_settings do
-            within_submenu do
+          hover_element(:admin_settings_item) do
+            within_submenu(:admin_sidebar_settings_submenu) do
               click_element :admin_settings_network_item
             end
           end
         end
 
+        def go_to_users_overview
+          within_submenu(:admin_sidebar_overview_submenu_content) do
+            click_element :users_overview_link
+          end
+        end
+
         private
 
-        def hover_settings
+        def hover_element(element)
           within_sidebar do
-            scroll_to_element(:admin_settings_item)
-            find_element(:admin_settings_item).hover
+            scroll_to_element(element)
+            find_element(element).hover
 
             yield
           end
@@ -83,8 +93,8 @@ module QA
           end
         end
 
-        def within_submenu
-          within_element(:admin_sidebar_submenu) do
+        def within_submenu(element)
+          within_element(element) do
             yield
           end
         end

qa/qa/page/admin/overview/users/index.rb

+# frozen_string_literal: true
+
+module QA
+  module Page
+    module Admin
+      module Overview
+        module Users
+          class Index < QA::Page::Base
+            view 'app/views/admin/users/index.html.haml' do
+              element :user_search_field
+            end
+
+            view 'app/views/admin/users/_user.html.haml' do
+              element :user_row_content
+            end
+
+            view 'app/views/admin/users/_user_detail.html.haml' do
+              element :username_link
+            end
+
+            def search_user(username)
+              find_element(:user_search_field).set(username).send_keys(:return)
+            end
+
+            def click_user(username)
+              within_element(:user_row_content, text: username) do
+                click_element(:username_link)
+              end
+            end
+          end
+        end
+      end
+    end
+  end
+end

qa/qa/page/admin/overview/users/show.rb

+# frozen_string_literal: true
+
+module QA
+  module Page
+    module Admin
+      module Overview
+        module Users
+          class Show < QA::Page::Base
+            view 'app/views/admin/users/_head.html.haml' do
+              element :impersonate_user_link
+            end
+
+            def click_impersonate_user
+              click_element(:impersonate_user_link)
+            end
+          end
+        end
+      end
+    end
+  end
+end

qa/qa/page/main/login.rb

@@ -42,7 +42,7 @@ module QA
           element :login_page, required: true
         end
 
-        def sign_in_using_credentials(user = nil)
+        def sign_in_using_credentials(user: nil, skip_page_validation: false)
           # Don't try to log-in if we're already logged-in
           return if Page::Main::Menu.perform(&:signed_in?)
 
@@ -52,9 +52,9 @@ module QA
             raise NotImplementedError if Runtime::User.ldap_user? && user&.credentials_given?
 
             if Runtime::User.ldap_user?
-              sign_in_using_ldap_credentials(user || Runtime::User)
+              sign_in_using_ldap_credentials(user: user || Runtime::User)
             else
-              sign_in_using_gitlab_credentials(user || Runtime::User)
+              sign_in_using_gitlab_credentials(user: user || Runtime::User, skip_page_validation: skip_page_validation)
             end
           end
         end
@@ -68,13 +68,13 @@ module QA
           using_wait_time 0 do
             set_initial_password_if_present
 
-            sign_in_using_gitlab_credentials(admin)
+            sign_in_using_gitlab_credentials(user: admin)
           end
 
           Page::Main::Menu.perform(&:has_personal_area?)
         end
 
-        def sign_in_using_ldap_credentials(user)
+        def sign_in_using_ldap_credentials(user:)
           Page::Main::Menu.perform(&:sign_out_if_signed_in)
 
           using_wait_time 0 do
@@ -148,18 +148,18 @@ module QA
         def sign_out_and_sign_in_as(user:)
           Menu.perform(&:sign_out_if_signed_in)
           has_sign_in_tab?
-          sign_in_using_credentials(user)
+          sign_in_using_credentials(user: user)
         end
 
         private
 
-        def sign_in_using_gitlab_credentials(user)
+        def sign_in_using_gitlab_credentials(user:, skip_page_validation: false)
           switch_to_sign_in_tab if has_sign_in_tab?
           switch_to_standard_tab if has_standard_tab?
 
           fill_element :login_field, user.username
           fill_element :password_field, user.password
-          click_element :sign_in_button, Page::Main::Menu
+          click_element :sign_in_button, !skip_page_validation && Page::Main::Menu
         end
 
         def set_initial_password_if_present

qa/qa/page/main/menu.rb

@@ -13,6 +13,7 @@ module QA
           element :navbar, required: true
           element :user_avatar, required: true
           element :user_menu, required: true
+          element :stop_impersonation_link
         end
 
         view 'app/views/layouts/nav/_dashboard.html.haml' do
@@ -95,6 +96,10 @@ module QA
           has_element?(:admin_area_link, wait: wait)
         end
 
+        def click_stop_impersonation_link
+          click_element(:stop_impersonation_link)
+        end
+
         private
 
         def within_top_menu

qa/qa/page/profile/emails.rb

+# frozen_string_literal: true
+
+module QA
+  module Page
+    module Profile
+      class Emails < Page::Base
+        view 'app/views/profiles/emails/index.html.haml' do
+          element :email_address_field
+          element :add_email_address_button
+          element :email_row_content
+          element :delete_email_link
+        end
+
+        def add_email_address(email_address)
+          find_element(:email_address_field).set email_address
+          click_element(:add_email_address_button)
+        end
+
+        def delete_email_address(email_address)
+          page.accept_alert do
+            within_element(:email_row_content, text: email_address) do
+              click_element(:delete_email_link)
+            end
+          end
+        end
+      end
+    end
+  end
+end

qa/qa/page/profile/menu.rb

@@ -9,6 +9,8 @@ module QA
           element :access_token_title, 'Access Tokens' # rubocop:disable QA/ElementWithPattern
           element :top_level_items, '.sidebar-top-level-items' # rubocop:disable QA/ElementWithPattern
           element :ssh_keys, 'SSH Keys' # rubocop:disable QA/ElementWithPattern
+          element :profile_emails_link
+          element :profile_password_link
         end
 
         def click_access_tokens
@@ -23,6 +25,18 @@ module QA
           end
         end
 
+        def click_emails
+          within_sidebar do
+            click_element(:profile_emails_link)
+          end
+        end
+
+        def click_password
+          within_sidebar do
+            click_element(:profile_password_link)
+          end
+        end
+
         private
 
         def within_sidebar

qa/qa/page/profile/password.rb

+# frozen_string_literal: true
+
+module QA
+  module Page
+    module Profile
+      class Password < Page::Base
+        view 'app/views/profiles/passwords/edit.html.haml' do
+          element :current_password_field
+          element :new_password_field
+          element :confirm_password_field
+          element :save_password_button
+        end
+
+        def update_password(new_password, current_password)
+          find_element(:current_password_field).set current_password
+          find_element(:new_password_field).set new_password
+          find_element(:confirm_password_field).set new_password
+          click_element(:save_password_button)
+        end
+      end
+    end
+  end
+end

qa/qa/resource/fork.rb

@@ -30,7 +30,7 @@ module QA
         Page::Main::Menu.perform(&:sign_out)
         Runtime::Browser.visit(:gitlab, Page::Main::Login)
         Page::Main::Login.perform do |login|
-          login.sign_in_using_credentials(user)
+          login.sign_in_using_credentials(user: user)
         end
 
         upstream.project.visit!

qa/qa/resource/user.rb

@@ -53,7 +53,7 @@ module QA
 
         if credentials_given?
           Page::Main::Login.perform do |login|
-            login.sign_in_using_credentials(self)
+            login.sign_in_using_credentials(user: self)
           end
         else
           Page::Main::Login.perform do |login|

qa/qa/runtime/api/client.rb

@@ -50,7 +50,7 @@ module QA
 
           unless Page::Main::Menu.perform { |p| p.has_personal_area?(wait: 0) }
             Runtime::Browser.visit(@address, Page::Main::Login)
-            Page::Main::Login.perform { |login| login.sign_in_using_credentials(@user) }
+            Page::Main::Login.perform { |login| login.sign_in_using_credentials(user: @user) }
           end
 
           token = Resource::PersonalAccessToken.fabricate!.access_token

spec/lib/gitlab/danger/helper_spec.rb

@@ -273,7 +273,7 @@ describe Gitlab::Danger::Helper do
     where(:category, :expected_label) do
       :backend   | '~backend'
       :database  | '~database'
-      :docs      | '~Documentation'
+      :docs      | '~documentation'
       :foo       | '~foo'
       :frontend  | '~frontend'
       :none      | ''