Add latest changes from gitlab-org/gitlab@master

11 files changed, 57 insertions, 77 deletions

diff --git a/doc/administration/operations/cleaning_up_redis_sessions.md b/doc/administration/operations/cleaning_up_redis_sessions.md
index 84cbfae2230..ed5014b65e1 100644
--- a/doc/administration/operations/cleaning_up_redis_sessions.md
+++ b/doc/administration/operations/cleaning_up_redis_sessions.md
@@ -1,64 +1,9 @@
 ---
-stage: Enablement
-group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+redirect_to: 'index.md'
+remove_date: '2021-12-10'
 ---
 
-# Cleaning up stale Redis sessions **(FREE SELF)**
+This document was moved to [another location](index.md).
 
-Since version 6.2, GitLab stores web user sessions as key-value pairs in Redis.
-Prior to GitLab 7.3, user sessions did not automatically expire from Redis. If
-you have been running a large GitLab server (thousands of users) since before
-GitLab 7.3 we recommend cleaning up stale sessions to compact the Redis
-database after you upgrade to GitLab 7.3. You can also perform a cleanup while
-still running GitLab 7.2 or older, but in that case new stale sessions will
-start building up again after you clean up.
-
-In GitLab versions prior to 7.3.0, the session keys in Redis are 16-byte
-hexadecimal values such as '976aa289e2189b17d7ef525a6702ace9'. Starting with
-GitLab 7.3.0, the keys are
-prefixed with `session:gitlab:`, so they would look like
-`session:gitlab:976aa289e2189b17d7ef525a6702ace9`. Below we describe how to
-remove the keys in the old format.
-
-NOTE:
-The instructions below must be modified in accordance with your
-configuration settings if you have used the advanced Redis
-settings outlined in
-[Configuration Files Documentation](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/README.md).
-
-First we define a shell function with the proper Redis connection details.
-
-```shell
-rcli() {
-  # This example works for Omnibus installations of GitLab 7.3 or newer. For an
-  # installation from source you will have to change the socket path and the
-  # path to redis-cli.
-  sudo /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket "$@"
-}
-
-# test the new shell function; the response should be PONG
-rcli ping
-```
-
-Now we do a search to see if there are any session keys in the old format for
-us to clean up.
-
-```shell
-# returns the number of old-format session keys in Redis
-rcli keys '*' | grep '^[a-f0-9]\{32\}$' | wc -l
-```
-
-If the number is larger than zero, you can proceed to expire the keys from
-Redis. If the number is zero there is nothing to clean up.
-
-```shell
-# Tell Redis to expire each matched key after 600 seconds.
-rcli keys '*' | grep '^[a-f0-9]\{32\}$' | awk '{ print "expire", $0, 600 }' | rcli
-# This will print '(integer) 1' for each key that gets expired.
-```
-
-Over the next 15 minutes (10 minutes expiry time plus 5 minutes Redis
-background save interval) your Redis database will be compacted. If you are
-still using GitLab 7.2, users who are not clicking around in GitLab during the
-10 minute expiry window will be signed out of GitLab.
+<!-- This redirect file can be deleted after 2021-12-10. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/administration/operations/extra_sidekiq_routing.md b/doc/administration/operations/extra_sidekiq_routing.md
index 6938f8a7012..68c6e546256 100644
--- a/doc/administration/operations/extra_sidekiq_routing.md
+++ b/doc/administration/operations/extra_sidekiq_routing.md
@@ -40,6 +40,8 @@ In `/etc/gitlab/gitlab.rb`:
 
 ```ruby
 sidekiq['routing_rules'] = [
+  # Do not re-route workers that require their own queue
+  ['tags=needs_own_queue', nil],
   # Route all non-CPU-bound workers that are high urgency to `high-urgency` queue
   ['resource_boundary!=cpu&urgency=high', 'high-urgency'],
   # Route all database, gitaly and global search workers that are throttled to `throttled` queue
@@ -164,3 +166,34 @@ with the migration to avoid losing jobs entirely, especially in a system with
 long queues of jobs. The migration can be done by following the migration steps
 mentioned in [Sidekiq job
 migration](../../raketasks/sidekiq_job_migration.md)
+
+### Workers that cannot be migrated
+
+Some workers cannot share a queue with other workers - typically because
+they check the size of their own queue - and so must be excluded from
+this process. We recommend excluding these from any further worker
+routing by adding a rule to keep them in their own queue, for example:
+
+```ruby
+sidekiq['routing_rules'] = [
+  ['tags=needs_own_queue', nil],
+  # ...
+]
+```
+
+These queues will also need to be included in at least one [Sidekiq
+queue group](extra_sidekiq_processes.md#start-multiple-processes).
+
+The following table shows the workers that should have their own queue:
+
+<!-- markdownlint-disable MD044 -->
+| Worker name | Queue name | GitLab issue |
+| --- | --- | --- |
+| EmailReceiverWorker | `email_receiver` | [gitlab-com/gl-infra/scalability#1263](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1263) |
+| ServiceDeskEmailReceiverWorker | `service_desk_email_receiver` | [gitlab-com/gl-infra/scalability#1263](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1263) |
+| ProjectImportScheduleWorker | `project_import_schedule` | [gitlab-org/gitlab#340630](https://gitlab.com/gitlab-org/gitlab/-/issues/340630) |
+| HashedStorage::MigratorWorker | `hashed_storage:hashed_storage_migrator` | [gitlab-org/gitlab#340629](https://gitlab.com/gitlab-org/gitlab/-/issues/340629) |
+| HashedStorage::ProjectMigrateWorker | `hashed_storage:hashed_storage_project_migrate` | [gitlab-org/gitlab#340629](https://gitlab.com/gitlab-org/gitlab/-/issues/340629) |
+| HashedStorage::ProjectRollbackWorker | `hashed_storage:hashed_storage_project_rollback` | [gitlab-org/gitlab#340629](https://gitlab.com/gitlab-org/gitlab/-/issues/340629) |
+| HashedStorage::RollbackerWorker | `hashed_storage:hashed_storage_rollbacker` | [gitlab-org/gitlab#340629](https://gitlab.com/gitlab-org/gitlab/-/issues/340629) |
+<!-- markdownlint-disable MD044 -->
diff --git a/doc/administration/operations/index.md b/doc/administration/operations/index.md
index 4b16c3b3a7e..7ccfa2739bb 100644
--- a/doc/administration/operations/index.md
+++ b/doc/administration/operations/index.md
@@ -8,11 +8,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Keep your GitLab instance up and running smoothly.
 
-- [Clean up Redis sessions](cleaning_up_redis_sessions.md): Prior to GitLab 7.3,
-  user sessions did not automatically expire from Redis. If
-  you have been running a large GitLab server (thousands of users) since before
-  GitLab 7.3 we recommend cleaning up stale sessions to compact the Redis
-  database after you upgrade to GitLab 7.3.
 - [Rake tasks](../../raketasks/index.md): Tasks for common administration and operational processes such as
   [cleaning up unneeded items from GitLab instance](../../raketasks/cleanup.md), integrity checks,
   and more.
diff --git a/doc/ci/environments/protected_environments.md b/doc/ci/environments/protected_environments.md
index 7caac7df64e..b7a651a330c 100644
--- a/doc/ci/environments/protected_environments.md
+++ b/doc/ci/environments/protected_environments.md
@@ -161,10 +161,6 @@ For more information, see [Deployment safety](deployment_safety.md).
 > - [Feature flag `group_level_protected_environments`](https://gitlab.com/gitlab-org/gitlab/-/issues/331085) removed in GitLab 14.3.
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/331085) in GitLab 14.3.
 
-This in-development feature might not be available for your use. There can be
-[risks when enabling features still in development](../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
-Refer to this feature's version history for more details.
-
 Typically, large enterprise organizations have an explicit permission boundary
 between [developers and operators](https://about.gitlab.com/topics/devops/).
 Developers build and test their code, and operators deploy and monitor the
diff --git a/doc/install/aws/eks_clusters_aws.md b/doc/install/aws/eks_clusters_aws.md
index 297303e5423..95f9f81f601 100644
--- a/doc/install/aws/eks_clusters_aws.md
+++ b/doc/install/aws/eks_clusters_aws.md
@@ -5,7 +5,7 @@ group: Alliances
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# EKS cluster provisioning best practices
+# EKS cluster provisioning best practices **(FREE SELF)**
 
 GitLab can be used to provision an EKS cluster into AWS, however, it necessarily focuses on a basic EKS configuration. Using the AWS tools can help with advanced cluster configuration, automation, and maintenance.
 
diff --git a/doc/install/aws/gitlab_sre_for_aws.md b/doc/install/aws/gitlab_sre_for_aws.md
index 8116fed4e39..a2d3a2d0295 100644
--- a/doc/install/aws/gitlab_sre_for_aws.md
+++ b/doc/install/aws/gitlab_sre_for_aws.md
@@ -7,7 +7,7 @@ description: Doing SRE for GitLab instances and runners on AWS.
 type: index
 ---
 
-# GitLab Site Reliability Engineering for AWS
+# GitLab Site Reliability Engineering for AWS **(FREE SELF)**
 
 ## Known issues list
 
diff --git a/doc/install/docker.md b/doc/install/docker.md
index b4faaa684db..9ccdc976488 100644
--- a/doc/install/docker.md
+++ b/doc/install/docker.md
@@ -4,7 +4,7 @@ group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# GitLab Docker images
+# GitLab Docker images **(FREE SELF)**
 
 The GitLab Docker images are monolithic images of GitLab running all the
 necessary services in a single container. If you instead want to install GitLab
diff --git a/doc/integration/kerberos.md b/doc/integration/kerberos.md
index 23565e6f370..48339144292 100644
--- a/doc/integration/kerberos.md
+++ b/doc/integration/kerberos.md
@@ -9,6 +9,11 @@ type: reference, how-to
 
 GitLab can integrate with [Kerberos](https://web.mit.edu/kerberos/) as an authentication mechanism.
 
+WARNING:
+GitLab CI/CD does not work with a Kerberos-enabled GitLab instance due to an unresolved
+[bug in Git CLI](https://lore.kernel.org/git/YKNVop80H8xSTCjz@coredump.intra.peff.net/T/#mab47fd7dcb61fee651f7cc8710b8edc6f62983d5)
+that fails to use job token authentication from the GitLab Runners.
+
 ## Overview
 
 [Kerberos](https://web.mit.edu/kerberos/) is a secure method for authenticating a request for a service in a
diff --git a/doc/raketasks/cleanup.md b/doc/raketasks/cleanup.md
index 9f79d3cc675..c2d3c540cbf 100644
--- a/doc/raketasks/cleanup.md
+++ b/doc/raketasks/cleanup.md
@@ -207,10 +207,6 @@ sudo gitlab-rake gitlab:cleanup:sessions:active_sessions_lookup_keys
 bundle exec rake gitlab:cleanup:sessions:active_sessions_lookup_keys RAILS_ENV=production
 ```
 
-## Cleaning up stale Redis sessions
-
-[Clean up stale sessions](../administration/operations/cleaning_up_redis_sessions.md) to compact the Redis database after you upgrade to GitLab 7.3.
-
 ## Container Registry garbage collection
 
 Container Registry can use considerable amounts of disk space. To clear up
diff --git a/doc/raketasks/features.md b/doc/raketasks/features.md
index 5c2c7b9222f..3248f7370e8 100644
--- a/doc/raketasks/features.md
+++ b/doc/raketasks/features.md
@@ -10,7 +10,8 @@ This Rake task enables [namespaces](../user/group/index.md#namespaces) for proje
 
 ## Enable usernames and namespaces for user projects
 
-This command enables the namespaces feature introduced in GitLab 4.0. It moves every project in its namespace folder.
+This command enables the namespaces feature. It moves every project in its
+namespace folder.
 
 The **repository location changes as part of this task**, so you must **update all your Git URLs** to
 point to the new location.
diff --git a/doc/user/compliance/license_compliance/index.md b/doc/user/compliance/license_compliance/index.md
index 566270f3774..7dd0e7241eb 100644
--- a/doc/user/compliance/license_compliance/index.md
+++ b/doc/user/compliance/license_compliance/index.md
@@ -49,6 +49,15 @@ When GitLab detects a **Denied** license, you can view it in the [license list](
 You can view and modify existing policies from the [policies](#policies) tab.
 ![Edit Policy](img/policies_maintainer_edit_v14_2.png)
 
+## License expressions
+
+GitLab has limited support for [composite licenses](https://spdx.github.io/spdx-spec/appendix-IV-SPDX-license-expressions/).
+License compliance can read multiple licenses, but always considers them combined using the `AND` operator. For example,
+if a dependency has two licenses, and one of them is allowed and the other is denied by the project [policy](#policies),
+GitLab evaluates the composite license as _denied_, as this is the safer option.
+The ability to support other license expression operators (like `OR`, `WITH`) is tracked
+in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/6571).
+
 ## Supported languages and package managers
 
 The following languages and package managers are supported.