Automatic merge of gitlab-org/gitlab-ce master

app/assets/javascripts/pages/profiles/keys/index.js

@@ -2,6 +2,8 @@ import AddSshKeyValidation from '~/profile/add_ssh_key_validation';
 
 document.addEventListener('DOMContentLoaded', () => {
   const input = document.querySelector('.js-add-ssh-key-validation-input');
+  if (!input) return;
+
   const warning = document.querySelector('.js-add-ssh-key-validation-warning');
   const originalSubmit = input.form.querySelector('.js-add-ssh-key-validation-original-submit');
   const confirmSubmit = warning.querySelector('.js-add-ssh-key-validation-confirm-submit');

changelogs/unreleased/fix-js-error-ssh-key-view.yml

+---
+title: disable SSH key validation in key details view
+merge_request: 28180
+author: Roger Meier
+type: fixed

doc/administration/auth/ldap.md

@@ -30,9 +30,9 @@ the LDAP server.
 
 ### User deletion
 
-If a user is deleted from the LDAP server, they will be blocked in GitLab, as
+If a user is deleted from the LDAP server, they will be blocked in GitLab as
 well. Users will be immediately blocked from logging in. However, there is an
-LDAP check cache time (sync time) of one hour (see note). This means users that
+LDAP check cache time of one hour (see note) which means users that
 are already logged in or are using Git over SSH will still be able to access
 GitLab for up to one hour. Manually block the user in the GitLab Admin area to
 immediately block all access.

doc/administration/high_availability/README.md

@@ -145,14 +145,38 @@ environments this is a good architecture to consider if you foresee or do have
 contention due to certain workloads.
 
 - 3 PostgreSQL nodes
+- 1 PgBouncer node
 - 2 Redis nodes
 - 3 Consul/Sentinel nodes
 - 2 or more Sidekiq nodes
-- 2 or more Web nodes (Unicorn, Workhorse, PGBouncer)
+- 2 or more GitLab application nodes (Unicorn, Workhorse)
 - 1 or more NFS/Gitaly servers
+- 1 Monitoring node (Prometheus, Grafana)
 
 ![Hybrid architecture diagram](https://docs.gitlab.com/ee/administration/img/high_availability/hybrid.png)
 
+#### Reference Architecture
+
+- **Status:** Work-in-progress
+- **Supported Users (approximate):** 10,000
+- **Related Issues:** [gitlab-com/support/support-team-meta#1513](https://gitlab.com/gitlab-com/support/support-team-meta/issues/1513), 
+ [gitlab-org/quality/team-tasks#110](https://gitlab.com/gitlab-org/quality/team-tasks/issues/110)
+
+The Support and Quality teams are in the process of building and performance testing
+an environment that will support about 10,000 users. The specifications below
+are a work-in-progress representation of the work so far. Quality will be 
+certifying this environment in FY20-Q2. The specifications may be adjusted 
+prior to certification based on performance testing. 
+
+- 3 PostgreSQL - 4 CPU, 8GB RAM
+- 1 PgBouncer - 2 CPU, 4GB RAM
+- 2 Redis - 2 CPU, 8GB RAM
+- 3 Consul/Sentinel - 2 CPU, 2GB RAM
+- 4 Sidekiq - 4 CPU, 8GB RAM
+- 5 GitLab application nodes - 20 CPU, 64GB RAM
+- 1 Gitaly - 20 CPU, 64GB RAM
+- 1 Monitoring node - 4 CPU, 8GB RAM
+
 ### Fully Distributed
 
 This architecture scales to hundreds of thousands of users and projects and is