Add latest changes from gitlab-org/gitlab@master

4 files changed, 121 insertions, 47 deletions

diff --git a/doc/administration/high_availability/README.md b/doc/administration/high_availability/README.md
index a1ac2486528..81c12279898 100644
--- a/doc/administration/high_availability/README.md
+++ b/doc/administration/high_availability/README.md
@@ -224,20 +224,20 @@ users are, how much automation you use, mirroring, and repo/change size.
   were discovered. For details, see the related issues list in
   [this issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/64335).
 
-| Service                       | Configuration           | GCP type       |
-| ------------------------------|-------------------------|----------------|
-| 3 GitLab Rails <br> - Puma workers on each node set to 90% of available CPUs with 16 threads | 32 vCPU, 28.8GB Memory | n1-highcpu-32 |
-| 3 PostgreSQL                  | 4 vCPU, 15GB Memory     | n1-standard-4  |
-| 1 PgBouncer                   | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
-| X Gitaly[^1] <br> - Gitaly Ruby workers on each node set to 20% of available CPUs | 16 vCPU, 60GB Memory   | n1-standard-16 |
-| 3 Redis Cache + Sentinel <br> - Cache maxmemory set to 90% of available memory | 4 vCPU, 15GB Memory | n1-standard-4 |
-| 3 Redis Persistent + Sentinel | 4 vCPU, 15GB Memory     | n1-standard-4  |
-| 4 Sidekiq                     | 4 vCPU, 15GB Memory     | n1-standard-4  |
-| 3 Consul                      | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
-| 1 NFS Server                  | 4 CPU, 3.6GB Memory     | n1-highcpu-4   |
-| X S3 Object Storage[^3]       | -                       | -              |
-| 1 Monitoring node             | 4 CPU, 3.6GB Memory     | n1-highcpu-4   |
-| 1 Load Balancing node[^2]     | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
+| Service                     | Nodes | Configuration         | GCP type      |
+| ----------------------------|-------|-----------------------|---------------|
+| GitLab Rails <br> - Puma workers on each node set to 90% of available CPUs with 16 threads | 3 | 32 vCPU, 28.8GB Memory | n1-highcpu-32 |
+| PostgreSQL                  | 3     | 4 vCPU, 15GB Memory   | n1-standard-4 |
+| PgBouncer                   | 1     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
+| Gitaly <br> - Gitaly Ruby workers on each node set to 20% of available CPUs | X[^1] . | 16 vCPU, 60GB Memory   | n1-standard-16 |
+| Redis Cache + Sentinel <br> - Cache maxmemory set to 90% of available memory | 3 | 4 vCPU, 15GB Memory | n1-standard-4 |
+| Redis Persistent + Sentinel | 3     | 4 vCPU, 15GB Memory   | n1-standard-4 |
+| Sidekiq                     | 4     | 4 vCPU, 15GB Memory   | n1-standard-4 |
+| Consul                      | 3     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
+| NFS Server[^4] .            | 1     | 4 CPU, 3.6GB Memory   | n1-highcpu-4  |
+| S3 Object Storage[^3] .     | -     | -                     | -             |
+| Monitoring node             | 1     | 4 CPU, 3.6GB Memory   | n1-highcpu-4  |
+| Load Balancing node[^2] .   | 1     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
 
 NOTE: **Note:** Memory values are given directly by GCP machine sizes. On different cloud
 vendors a best effort like for like can be used.
@@ -251,20 +251,20 @@ vendors a best effort like for like can be used.
   details, see the related issues list in
   [this issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/64335).
 
-| Service                       | Configuration           | GCP type       |
-| ------------------------------|-------------------------|----------------|
-| 7 GitLab Rails <br> - Puma workers on each node set to 90% of available CPUs with 16 threads | 32 vCPU, 28.8GB Memory | n1-highcpu-32 |
-| 3 PostgreSQL                  | 8 vCPU, 30GB Memory     | n1-standard-8  |
-| 1 PgBouncer                   | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
-| X Gitaly[^1] <br> - Gitaly Ruby workers on each node set to 20% of available CPUs | 32 vCPU, 120GB Memory   | n1-standard-32 |
-| 3 Redis Cache + Sentinel <br> - Cache maxmemory set to 90% of available memory | 4 vCPU, 15GB Memory | n1-standard-4 |
-| 3 Redis Persistent + Sentinel | 4 vCPU, 15GB Memory     | n1-standard-4  |
-| 4 Sidekiq                     | 4 vCPU, 15GB Memory     | n1-standard-4  |
-| 3 Consul                      | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
-| 1 NFS Server                  | 4 CPU, 3.6GB Memory     | n1-highcpu-4   |
-| X S3 Object Storage[^4]       | -                       | -              |
-| 1 Monitoring node             | 4 CPU, 3.6GB Memory     | n1-highcpu-4   |
-| 1 Load Balancing node[^2]     | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
+| Service                     | Nodes | Configuration         | GCP type      |
+| ----------------------------|-------|-----------------------|---------------|
+| GitLab Rails <br> - Puma workers on each node set to 90% of available CPUs with 16 threads | 7 | 32 vCPU, 28.8GB Memory | n1-highcpu-32 |
+| PostgreSQL                  | 3     | 8 vCPU, 30GB Memory   | n1-standard-8 |
+| PgBouncer                   | 1     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
+| Gitaly <br> - Gitaly Ruby workers on each node set to 20% of available CPUs | X[^1] . | 32 vCPU, 120GB Memory | n1-standard-32 |
+| Redis Cache + Sentinel <br> - Cache maxmemory set to 90% of available memory | 3 | 4 vCPU, 15GB Memory | n1-standard-4 |
+| Redis Persistent + Sentinel | 3     | 4 vCPU, 15GB Memory   | n1-standard-4 |
+| Sidekiq                     | 4     | 4 vCPU, 15GB Memory   | n1-standard-4 |
+| Consul                      | 3     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
+| NFS Server[^4] .            | 1     | 4 CPU, 3.6GB Memory   | n1-highcpu-4  |
+| S3 Object Storage[^3] .     | -     | -                     | -             |
+| Monitoring node             | 1     | 4 CPU, 3.6GB Memory   | n1-highcpu-4  |
+| Load Balancing node[^2] .   | 1     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
 
 NOTE: **Note:** Memory values are given directly by GCP machine sizes. On different cloud
 vendors a best effort like for like can be used.
@@ -280,20 +280,20 @@ NOTE: **Note:**  This architecture is a work-in-progress of the work so far. The
 Quality team will be certifying this environment in late 2019. The specifications
 may be adjusted prior to certification based on performance testing.
 
-| Service                       | Configuration           | GCP type       |
-| ------------------------------|-------------------------|----------------|
-| 15 GitLab Rails <br> - Puma workers on each node set to 90% of available CPUs with 16 threads | 32 vCPU, 28.8GB Memory | n1-highcpu-32 |
-| 3 PostgreSQL                  | 8 vCPU, 30GB Memory     | n1-standard-8  |
-| 1 PgBouncer                   | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
-| X Gitaly[^1] <br> - Gitaly Ruby workers on each node set to 20% of available CPUs | 64 vCPU, 240GB Memory   | n1-standard-64 |
-| 3 Redis Cache + Sentinel <br> - Cache maxmemory set to 90% of available memory | 4 vCPU, 15GB Memory | n1-standard-4 |
-| 3 Redis Persistent + Sentinel | 4 vCPU, 15GB Memory     | n1-standard-4  |
-| 4 Sidekiq                     | 4 vCPU, 15GB Memory     | n1-standard-4  |
-| 3 Consul                      | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
-| 1 NFS Server                  | 4 CPU, 3.6GB Memory     | n1-highcpu-4   |
-| X S3 Object Storage[^3]       | -                       | -              |
-| 1 Monitoring node             | 4 CPU, 3.6GB Memory     | n1-highcpu-4   |
-| 1 Load Balancing node[^2]     | 2 vCPU, 1.8GB Memory    | n1-highcpu-2   |
+| Service                     | Nodes | Configuration         | GCP type      |
+| ----------------------------|-------|-----------------------|---------------|
+| GitLab Rails <br> - Puma workers on each node set to 90% of available CPUs with 16 threads | 15 | 32 vCPU, 28.8GB Memory | n1-highcpu-32 |
+| PostgreSQL                  | 3     | 8 vCPU, 30GB Memory   | n1-standard-8 |
+| PgBouncer                   | 1     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
+| Gitaly <br> - Gitaly Ruby workers on each node set to 20% of available CPUs | X[^1] . | 64 vCPU, 240GB Memory   | n1-standard-64 |
+| Redis Cache + Sentinel <br> - Cache maxmemory set to 90% of available memory | 3 | 4 vCPU, 15GB Memory | n1-standard-4 |
+| Redis Persistent + Sentinel | 3     | 4 vCPU, 15GB Memory   | n1-standard-4 |
+| Sidekiq                     | 4     | 4 vCPU, 15GB Memory   | n1-standard-4 |
+| Consul                      | 3     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
+| NFS Server[^4] .            | 1     | 4 CPU, 3.6GB Memory   | n1-highcpu-4  |
+| S3 Object Storage[^3] .     | -     | -                     | -             |
+| Monitoring node             | 1     | 4 CPU, 3.6GB Memory   | n1-highcpu-4  |
+| Load Balancing node[^2] .   | 1     | 2 vCPU, 1.8GB Memory  | n1-highcpu-2  |
 
 NOTE: **Note:** Memory values are given directly by GCP machine sizes. On different cloud
 vendors a best effort like for like can be used.
diff --git a/doc/api/deployments.md b/doc/api/deployments.md
index f4264866014..6fc6599a47d 100644
--- a/doc/api/deployments.md
+++ b/doc/api/deployments.md
@@ -11,7 +11,7 @@ GET /projects/:id/deployments
 | Attribute | Type    | Required | Description         |
 |-----------|---------|----------|---------------------|
 | `id`      | integer/string | yes      | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
-| `order_by`| string  | no       | Return deployments ordered by `id` or `iid` or `created_at` or `ref` fields. Default is `id` |
+| `order_by`| string  | no       | Return deployments ordered by `id` or `iid` or `created_at` or `updated_at` or `ref` fields. Default is `id` |
 | `sort`    | string  | no       | Return deployments sorted in `asc` or `desc` order. Default is `asc` |
 
 ```bash
diff --git a/doc/development/gotchas.md b/doc/development/gotchas.md
index c7eed880554..da27ae9110b 100644
--- a/doc/development/gotchas.md
+++ b/doc/development/gotchas.md
@@ -168,3 +168,73 @@ in an initializer._
 ### Further reading
 
 - Stack Overflow: [Why you should not write inline JavaScript](https://softwareengineering.stackexchange.com/questions/86589/why-should-i-avoid-inline-scripting)
+
+## Auto loading
+
+Rails auto-loading on `development` differs from the load policy in the `production` environment.
+In development mode, `config.eager_load` is set to `false`, which means classes
+are loaded as needed. With the classic Rails autoloader, it is known that this can lead to
+[Rails resolving the wrong class](https://guides.rubyonrails.org/v5.2/autoloading_and_reloading_constants.html#when-constants-aren-t-missed-relative-references)
+if the class name is ambiguous. This can be fixed by specifying the complete namespace to the class.
+
+### Error prone example
+
+```ruby
+# app/controllers/application_controller.rb
+class ApplicationController < ActionController::Base
+  ...
+end
+
+# app/controllers/projects/application_controller.rb
+class Projects::ApplicationController < ApplicationController
+  ...
+  private
+
+  def project
+    ...
+  end
+end
+
+# app/controllers/projects/submodule/some_controller.rb
+module Projects
+  module Submodule
+    class SomeController < ApplicationController
+      def index
+        @some_id = project.id
+      end
+    end
+  end
+end
+```
+
+In this case, if for any reason the top level `ApplicationController`
+is loaded but `Projects::ApplicationController` is not, `ApplicationController`
+would be resolved to `::ApplicationController` and then the `project` method will
+be undefined and we will get an error.
+
+#### Solution
+
+```ruby
+# app/controllers/projects/submodule/some_controller.rb
+module Projects
+  module Submodule
+    class SomeController < Projects::ApplicationController
+      def index
+        @some_id = project.id
+      end
+    end
+  end
+end
+```
+
+By specifying `Projects::`, we tell Rails exactly what class we are referring
+to and we would avoid the issue.
+
+NOTE: **Note:**
+This problem will disappear as soon as we upgrade to Rails 6 and use the Zeitwerk autoloader.
+
+### Further reading
+
+- Rails Guides: [Autoloading and Reloading Constants (Classic Mode)](https://guides.rubyonrails.org/autoloading_and_reloading_constants_classic_mode.html)
+- Ruby Constant lookup: [Everything you ever wanted to know about constant lookup in Ruby](http://cirw.in/blog/constant-lookup)
+- Rails 6 and Zeitwerk autoloader: [Understanding Zeitwerk in Rails 6](https://medium.com/cedarcode/understanding-zeitwerk-in-rails-6-f168a9f09a1f)
diff --git a/doc/user/project/issues/design_management.md b/doc/user/project/issues/design_management.md
index c9f06c6339e..594f73dbfbe 100644
--- a/doc/user/project/issues/design_management.md
+++ b/doc/user/project/issues/design_management.md
@@ -114,12 +114,16 @@ viewed by browsing previous versions.
 
 ## Adding annotations to designs
 
-When a design image is displayed, you can add annotations to it by clicking on
-the image. A badge is added to the image and a form is displayed to start a new
-discussion. For example:
+When a design is uploaded, you can add annotations by clicking on
+the image on the exact location you'd like to add the note to.
+A badge is added to the image identifying the annotation, from
+which you can start a new discussion:
 
 ![Starting a new discussion on design](img/adding_note_to_design_1.png)
 
-When submitted, the form saves a badge linked to the discussion on the image. Different discussions have different badge numbers. For example:
+Different discussions have different badge numbers:
 
 ![Discussions on design annotations](img/adding_note_to_design_2.png)
+
+From GitLab 12.5 on, new annotations will be outputted to the issue activity,
+so that everyone involved can participate in the discussion.