Add latest changes from gitlab-org/gitlab@master

4 files changed, 64 insertions, 13 deletions

diff --git a/doc/administration/auth/ldap-ee.md b/doc/administration/auth/ldap-ee.md
index 3220831ea87..c5e4bee3c58 100644
--- a/doc/administration/auth/ldap-ee.md
+++ b/doc/administration/auth/ldap-ee.md
@@ -493,7 +493,7 @@ step of the sync.
 1. Run a group sync for this particular group.
 
    ```ruby
-   EE::Gitlab::Auth::LDAP::Sync::Group.execute_all_providers(group)
+   EE::Gitlab::Auth::Ldap::Sync::Group.execute_all_providers(group)
    ```
 
 1. Look through the output of the sync. See [example log output](#example-log-output)
@@ -503,11 +503,11 @@ step of the sync.
    run the following query:
 
    ```ruby
-   adapter = Gitlab::Auth::LDAP::Adapter.new('ldapmain') # If `main` is the LDAP provider
-   ldap_group = EE::Gitlab::Auth::LDAP::Group.find_by_cn('group_cn_here', adapter)
+   adapter = Gitlab::Auth::Ldap::Adapter.new('ldapmain') # If `main` is the LDAP provider
+   ldap_group = EE::Gitlab::Auth::Ldap::Group.find_by_cn('group_cn_here', adapter)
 
    # Output
-   => #<EE::Gitlab::Auth::LDAP::Group:0x007fcbdd0bb6d8
+   => #<EE::Gitlab::Auth::Ldap::Group:0x007fcbdd0bb6d8
    ```
 
 1. Query the LDAP group's member DNs and see if the user's DN is in the list.
diff --git a/doc/administration/high_availability/README.md b/doc/administration/high_availability/README.md
index 9b5cabae39a..b7ac9916ea3 100644
--- a/doc/administration/high_availability/README.md
+++ b/doc/administration/high_availability/README.md
@@ -9,8 +9,8 @@ ensure that they are scalable and highly available. While these needs can be tac
 individually, they typically go hand in hand: a performant scalable environment
 will have availability by default, as its components are separated and pooled.
 
-On this page, we present recommendations for setups based on the number
-of users you expect. For larger setups we give several recommended
+On this page, we present a maturity model for a progression from simple to complex
+GitLab installations as your GitLab usage evolves. For larger setups we give several recommended
 architectures based on experience with GitLab.com and internal scale
 testing that aim to achieve the right balance between both scalability
 and availability.
@@ -20,9 +20,60 @@ watch [this 1 hour Q&A](https://www.youtube.com/watch?v=uCU8jdYzpac)
 with [John Northrup](https://gitlab.com/northrup), and live questions coming
 in from some of our customers.
 
+## Maturity levels
+
+### Level 1: Single-node Omnibus installation
+
+This solution is appropriate for many teams that have a single server at their disposal. With automatic backup of the GitLab repositories, configuration, and the database, this can be an optimal solution if you don't have strict availability requirements.
+
+This configuration is supported in [GitLab Starter, Premium and Ultimate](https://about.gitlab.com/pricing/).
+
+References:
+
+- [Installation Docs](../../install/README.html)
+- [Backup/Restore Docs](https://docs.gitlab.com/omnibus/settings/backups.html#backup-and-restore-omnibus-gitlab-configuration)
+
+### Level 2: Multiple application servers
+
+By separating components you can see a number of advantages compared to a single-node setup. Namely, you can:
+
+- Increase the number of users
+- Enable zero-downtime upgrades
+- Increase availability
+
+Additional application nodes will handle frontend traffic, with a load balancer in front to distribute traffic across those nodes. Meanwhile, each application node connects to a shared file server and database systems on the back end. This way, if one of the application servers fails, the workflow is not interrupted.
+
+This configuration is supported in [GitLab Starter, Premium and Ultimate](https://about.gitlab.com/pricing/).
+
+References:
+
+- [High Availability Reference Architectures](#reference-architectures), without HA components
+
+### Level 3: Highly Available
+
+By adding automatic failover for database systems, we can enable higher uptime with an additional layer of complexity.
+
+This configuration is supported in [GitLab Premium and Ultimate](https://about.gitlab.com/pricing/).
+
+References:
+
+- [High Availability Reference Architectures](#reference-architectures)
+
+### Level 4: GitLab Geo
+
+GitLab Geo allows you to replicate your GitLab instance to other geographical locations as a read-only fully operational instance that can also be promoted in case of disaster.
+
+This configuration is supported in [GitLab Premium and Ultimate](https://about.gitlab.com/pricing/).
+
+References:
+
+- [Geo Documentation](../../gitlab-geo/README.html)
+- [GitLab Geo with a highly available configuration](../geo/replication/high_availability.html)
+
 ## Recommended setups based on number of users
 
 - 1 - 1000 Users: A single-node [Omnibus](https://docs.gitlab.com/omnibus/) setup with frequent backups. Refer to the [requirements page](../../install/requirements.md) for further details of the specs you will require.
+- 1000 - 10000 Users: A scaled environment based on one of our [Reference Architectures](#reference-architectures), without the HA components applied. This can be a reasonable step towards a fully HA environment.
 - 2000 - 50000+ Users: A scaled HA environment based on one of our [Reference Architectures](#reference-architectures) below.
 
 ## GitLab components and configuration instructions
diff --git a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
index 16eb3269ef0..2bb2e13511c 100644
--- a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
+++ b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
@@ -626,7 +626,7 @@ EE::Gitlab::LDAP::Sync::Group.execute_all_providers(group)
 
 # Run a GroupSync for a single group (10.6+)
 group = Group.find_by(name: 'my_gitlab_group')
-EE::Gitlab::Auth::LDAP::Sync::Group.execute_all_providers(group)
+EE::Gitlab::Auth::Ldap::Sync::Group.execute_all_providers(group)
 
 # Query an LDAP group directly (10.6-)
 adapter = Gitlab::LDAP::Adapter.new('ldapmain') # If `main` is the LDAP provider
@@ -635,20 +635,20 @@ ldap_group.member_dns
 ldap_group.member_uids
 
 # Query an LDAP group directly (10.6+)
-adapter = Gitlab::Auth::LDAP::Adapter.new('ldapmain') # If `main` is the LDAP provider
-ldap_group = EE::Gitlab::Auth::LDAP::Group.find_by_cn('group_cn_here', adapter)
+adapter = Gitlab::Auth::Ldap::Adapter.new('ldapmain') # If `main` is the LDAP provider
+ldap_group = EE::Gitlab::Auth::Ldap::Group.find_by_cn('group_cn_here', adapter)
 ldap_group.member_dns
 ldap_group.member_uids
 
 # Lookup a particular user (10.6+)
 # This could expose potential errors connecting to and/or querying LDAP that may seem to
 # fail silently in the GitLab UI
-adapter = Gitlab::Auth::LDAP::Adapter.new('ldapmain') # If `main` is the LDAP provider
-user = Gitlab::Auth::LDAP::Person.find_by_uid('<username>',adapter)
+adapter = Gitlab::Auth::Ldap::Adapter.new('ldapmain') # If `main` is the LDAP provider
+user = Gitlab::Auth::Ldap::Person.find_by_uid('<username>',adapter)
 
 # Query the LDAP server directly (10.6+)
 ## For an example, see https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/ee/gitlab/auth/ldap/adapter.rb
-adapter = Gitlab::Auth::LDAP::Adapter.new('ldapmain')
+adapter = Gitlab::Auth::Ldap::Adapter.new('ldapmain')
 options = {
     # the :base is required
     # use adapter.config.base for the base or .group_base for the group_base
diff --git a/doc/ci/merge_request_pipelines/index.md b/doc/ci/merge_request_pipelines/index.md
index 448525efbde..d1749924ad3 100644
--- a/doc/ci/merge_request_pipelines/index.md
+++ b/doc/ci/merge_request_pipelines/index.md
@@ -188,7 +188,7 @@ External users could steal secret variables from the parent project by modifying
 
 We're discussing a secure solution of running pipelines for merge requests
 that are submitted from forked projects,
-see [the issue about the permission extension](https://gitlab.com/gitlab-org/gitlab-foss/issues/23902).
+see [the issue about the permission extension](https://gitlab.com/gitlab-org/gitlab/-/issues/11934).
 
 ## Additional predefined variables