kotovalexarian-likes-gitlab
/
gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2019-09-23 06:06:19 +00:00
parent 98dbb0a488
commit 89861e72b7
57 changed files with 331 additions and 219 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.gitlab/issue_templates/Coding style proposal.md
View File

@ -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

6
.gitlab/issue_templates/Doc Review.md
View File

@ -8,13 +8,13 @@
## References
Merged MR that introduced documentation requiring review:
Merged MR that introduced documentation requiring review:
Related issue(s):
Related issue(s):
## Further Details
<!-- Any additional context, questions, or notes for the technical writer. -->
/label ~Documentation ~docs-review
/label ~documentation ~"Technical Writing"

16
.gitlab/issue_templates/Documentation.md
View File

@ -2,23 +2,13 @@
* Use this issue template for suggesting new docs or updates to existing docs.
Note: Doc work as part of feature development is covered in the Feature Request template.
* For issues related to features of the docs.gitlab.com site, see
https://gitlab.com/gitlab-org/gitlab-docs/issues/
https://gitlab.com/gitlab-org/gitlab-docs/issues/
* 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

6
.gitlab/merge_request_templates/Change documentation location.md
View File

@ -10,12 +10,12 @@
<!-- Mention the issue(s) this MR closes or is related to -->
Closes
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

6
.gitlab/merge_request_templates/Documentation.md
View File

@ -1,5 +1,5 @@
<!-- Follow the documentation workflow https://docs.gitlab.com/ee/development/documentation/workflow.html -->
<!-- Additional information is located at https://docs.gitlab.com/ee/development/documentation/ -->
<!-- Additional information is located at https://docs.gitlab.com/ee/development/documentation/ -->
<!-- Mention "documentation" or "docs" in the MR title -->
<!-- For changing documentation location use the "Change documentation location" template -->
@ -26,7 +26,7 @@ All reviewers can help ensure accuracy, clarity, completeness, and adherence to
**1. Primary Reviewer**
* [ ] Review by a code reviewer or other selected colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes.
**2. Technical Writer**
* [ ] Optional: Technical writer review. If not requested for this MR, must be scheduled post-merge. To request for this MR, assign the writer listed for the applicable [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages).
@ -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

2
app/views/admin/users/_head.html.haml
View File

@ -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

2
app/views/admin/users/_user.html.haml
View File

@ -1,4 +1,4 @@
.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')

2
app/views/admin/users/_user_detail.html.haml
View File

@ -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

2
app/views/admin/users/index.html.haml
View File

@ -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")

2
app/views/layouts/header/_default.html.haml
View File

@ -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

10
app/views/layouts/nav/sidebar/_admin.html.haml
View File

@ -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

4
app/views/layouts/nav/sidebar/_profile.html.haml
View File

@ -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

8
app/views/profiles/emails/index.html.haml
View File

@ -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')

8
app/views/profiles/passwords/edit.html.haml
View File

@ -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"

4
danger/documentation/Dangerfile
View File

@ -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

3
doc/administration/geo/disaster_recovery/index.md
View File

@ -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

5
doc/administration/geo/replication/configuration.md
View File

@ -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

8
doc/administration/geo/replication/database.md
View File

@ -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:

4
doc/administration/geo/replication/faq.md
View File

@ -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?

20
doc/administration/geo/replication/high_availability.md
View File

@ -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.

4
doc/administration/geo/replication/index.md
View File

@ -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.

6
doc/administration/geo/replication/security_review.md
View File

@ -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.

6
doc/administration/geo/replication/troubleshooting.md
View File

@ -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:

2
doc/administration/geo/replication/using_a_geo_server.md
View File

@ -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:

6
doc/administration/high_availability/README.md
View File

@ -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

10
doc/administration/high_availability/consul.md
View File

@ -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.

66
doc/administration/high_availability/database.md
View File

@ -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

6
doc/administration/high_availability/gitlab.md
View File

@ -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

14
doc/administration/high_availability/load_balancer.md
View File

@ -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

4
doc/administration/high_availability/nfs.md
View File

@ -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.
```

4
doc/administration/high_availability/nfs_host_client_setup.md
View File

@ -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"}})

34
doc/administration/high_availability/pgbouncer.md
View File

@ -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

10
doc/administration/high_availability/redis.md
View File

@ -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.

2
doc/administration/high_availability/redis_source.md
View File

@ -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

4
doc/api/settings.md
View File

@ -1,7 +1,3 @@
---
table_display_block: true
---
# Application settings API
These API calls allow you to read and modify GitLab instance

1
doc/ci/variables/README.md
View File

@ -1,5 +1,4 @@
---
table_display_block: true
type: reference
---

4
doc/development/architecture.md
View File

@ -1,7 +1,3 @@
---
table_display_block: true
---
# GitLab Architecture Overview
## Software delivery

7
doc/development/contributing/issue_workflow.md
View File

@ -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

4
doc/development/documentation/feature-change-workflow.md
View File

@ -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:

14
doc/development/documentation/styleguide.md
View File

@ -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**`).

4
doc/user/admin_area/geo_nodes.md
View File

@ -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.

4
doc/user/application_security/sast/analyzers.md
View File

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

6
doc/user/gitlab_com/index.md
View File

@ -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

2
lib/gitlab/danger/helper.rb
View File

@ -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/*`",

9
qa/qa.rb
View File

@ -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

46
qa/qa/page/admin/menu.rb
View File

@ -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

35
qa/qa/page/admin/overview/users/index.rb Normal file
View File

@ -0,0 +1,35 @@
# 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

21
qa/qa/page/admin/overview/users/show.rb Normal file
View File

@ -0,0 +1,21 @@
# 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

16
qa/qa/page/main/login.rb
View File

@ -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

5
qa/qa/page/main/menu.rb
View File

@ -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

29
qa/qa/page/profile/emails.rb Normal file
View File

@ -0,0 +1,29 @@
# 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

14
qa/qa/page/profile/menu.rb
View File

@ -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

23
qa/qa/page/profile/password.rb Normal file
View File

@ -0,0 +1,23 @@
# 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

2
qa/qa/resource/fork.rb
View File

@ -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!

2
qa/qa/resource/user.rb
View File

@ -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|

2
qa/qa/runtime/api/client.rb
View File

@ -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

2
spec/lib/gitlab/danger/helper_spec.rb
View File

@ -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 | ''